Domain: fluent-access.com
Stories and comments across the archive that link to fluent-access.com.
Stories · 4
-
Cure For Bad Software? Legal Liability
satch89450 writes: "SecurityFocus had a column that I missed when it was first published a few days ago, titled 'Responsible Disclosure' Draft Could Have Legal Muscle, but I discovered it when researching an answer to a comment on the CYBERIA mailing list. In this article, Mark Rasch discusses how the Draft would set the rules for reporting security vunerabilities, and in particular define the boundaries of liability assumed by bug-disclosers. By adopting a "Best Practices" RFC, the IETF could help the reporters of security-related bugs do their job, and put the onus of fixing the bugs on the vendors who make the mistakes, where it belongs. (The RFC draft described in the article, 'Responsible Vulnerability Disclosure Process, is here at the ISI repository.) This is, of course, in direct opposition to the process that Microsoft's Scott Culp, Manager of the Microsoft Security Response Center, would like to see. As Microsoft is more part of the problem than part of the solution, I believe that the path to a formal process would better serve the entire community - and that community includes Microsoft's customers. I'm taking this seriously because the mainstream press is talking about the issue, and what it's going to take to fix it. Here is an example from BusinessWeek that scares me silly. I'm glad I'm looking to change careers from software development to something safe, like law." -
Bush Won't Be "The Online President"
satch89450 writes: "The Electronic Telegraph says here that President Bush has retired his electronic mail habit, citing FOIA access. As a point in fact, The New York Times reportedly obtained a copy of the farewell e-letter to 42 of Bush's friends. Just how bad can it get? Here is an old news report from The Associated Press via amarillonet of an auction of the 1992 e-mail to John Glenn. Privacy advocates should be scared ..." And an Anonymous Coward who points to the same article asks: "Whatever happened to the right of the people to be secure in their ... papers, and effects, against unreasonable searches and seizures?" Good question -- what did happen to that? -
Funding Linux TCP/IP Stack Documentation Project?
satch89450 asks: "I am one of the authors of the book Linux IP Stacks Commentary published by Coriolis Press. This book comments the TCP/IP code in Linux kernel 2.0.34. The history of the book is described here in detail, including our reasons for 'leapfrogging' the 2.2 releases and going right to 2.4. Yes, it's long past time to update the book, especially as kernel 2.4.0 has many, many changes in the TCP/IP code and is in test release as you read this. Our problem is how to fund the effort. Coriolis appears not to be interested in another round at this time. Heather and I are both professional writers, and that's how we make our living. Given the amount of work, donating the effort is out of the question -- it wouldn't keep kibble in the kitty bowls and have the material available in a timely fashion. We're looking for ideas." One of the largest complaints about Linux is that there is a lack of high-profile documentation. It would be sad if this publication were not made simply because of the lack of funds (which some people would see as a lack of interest) necessary to complete it."Doing the update as a Second Edition (even if Coriolis was on board) means that useful information wouldn't be available until sometime in 2001 -- at which time the information will be obsolete again. Based on reader feedback, that simply isn't acceptable. The format of the First Edition is incredibly hostile to incremental publication. So Heather and I have decided to start over, completely re-designing and re-writing the book from scratch, incorporate additional information that was beyond the scope of the original book, and publish it incrementally on the Web. We have figured out the mechanics: we have a rough page design, we have a start on the publishing automation tools, and we have a Web server.
Based on some suggestions (one from a /. reader) here are the options as we see them for funding this project:
-
Subscriptions: Our original idea (mentioned in our page) was to sell subscriptions to access most of the material; some material would be open to show what we do. Buyers of our book would get a discount on their first subscription, based on the fact they had bought our book. To keep overhead down, we were expecting to sell subscriptions on a quarterly and annual basis. We thought that $12/year or $4/quarter would strike a good balance. (We would also investigate how to accept subscriptions in currency other that U.S. dollars.)
-
Advertising: The old standby, banner ads, is the most distasteful option, but one that we have to consider. I've noticed that a number of Linux sites use banner ads to help fund the effort. In our page design, we want to maximize the use of Web page real estate to show code and commentary, not ads. There are a couple of issues, such as where to place the ads, that would need to be addressed, but given the page design we would incorporate the ads in the commentary, and not the code or control panes.
-
Contributions: Grants and subsidies from interested parties would help the project; if the contributions were large enough we could abandon both advertising and subscription completely and make the site open to all. We would use the Seti@Home treatment of contributions as a model, so that everyone who contributes can be recognized. Where would we put out our tin cup?
-
The Eudora Model: One mixture that might work is to mimic the model used by Qualcomm's Eudora MUA for Windows and Macintosh: display ads to those who want to use the "free" service and suppress ads for those who subscribe. This adds a little complexity (and an annoyance to the free users) but it means the information would be available to all.
I'm sure these aren't the only way to do the trick that keeps us off the street. I welcome comments, suggestions, and brick-bats from Slashdotters.
Why not 'open source' the book as well? Part of the reason Heather and I didn't try to farm out the code analysis is that we wanted to have a consistent style. Frankly, it would be as much work to accept contributions and then edit them for style and structure as it would be to do the entire job ourselves. In one sense, the book will be open source in that readers will be able to post "yellow stickies" on our commentary...and readers can see the yellow-stickies (with attribution)."
-
-
Funding Linux TCP/IP Stack Documentation Project?
satch89450 asks: "I am one of the authors of the book Linux IP Stacks Commentary published by Coriolis Press. This book comments the TCP/IP code in Linux kernel 2.0.34. The history of the book is described here in detail, including our reasons for 'leapfrogging' the 2.2 releases and going right to 2.4. Yes, it's long past time to update the book, especially as kernel 2.4.0 has many, many changes in the TCP/IP code and is in test release as you read this. Our problem is how to fund the effort. Coriolis appears not to be interested in another round at this time. Heather and I are both professional writers, and that's how we make our living. Given the amount of work, donating the effort is out of the question -- it wouldn't keep kibble in the kitty bowls and have the material available in a timely fashion. We're looking for ideas." One of the largest complaints about Linux is that there is a lack of high-profile documentation. It would be sad if this publication were not made simply because of the lack of funds (which some people would see as a lack of interest) necessary to complete it."Doing the update as a Second Edition (even if Coriolis was on board) means that useful information wouldn't be available until sometime in 2001 -- at which time the information will be obsolete again. Based on reader feedback, that simply isn't acceptable. The format of the First Edition is incredibly hostile to incremental publication. So Heather and I have decided to start over, completely re-designing and re-writing the book from scratch, incorporate additional information that was beyond the scope of the original book, and publish it incrementally on the Web. We have figured out the mechanics: we have a rough page design, we have a start on the publishing automation tools, and we have a Web server.
Based on some suggestions (one from a /. reader) here are the options as we see them for funding this project:
-
Subscriptions: Our original idea (mentioned in our page) was to sell subscriptions to access most of the material; some material would be open to show what we do. Buyers of our book would get a discount on their first subscription, based on the fact they had bought our book. To keep overhead down, we were expecting to sell subscriptions on a quarterly and annual basis. We thought that $12/year or $4/quarter would strike a good balance. (We would also investigate how to accept subscriptions in currency other that U.S. dollars.)
-
Advertising: The old standby, banner ads, is the most distasteful option, but one that we have to consider. I've noticed that a number of Linux sites use banner ads to help fund the effort. In our page design, we want to maximize the use of Web page real estate to show code and commentary, not ads. There are a couple of issues, such as where to place the ads, that would need to be addressed, but given the page design we would incorporate the ads in the commentary, and not the code or control panes.
-
Contributions: Grants and subsidies from interested parties would help the project; if the contributions were large enough we could abandon both advertising and subscription completely and make the site open to all. We would use the Seti@Home treatment of contributions as a model, so that everyone who contributes can be recognized. Where would we put out our tin cup?
-
The Eudora Model: One mixture that might work is to mimic the model used by Qualcomm's Eudora MUA for Windows and Macintosh: display ads to those who want to use the "free" service and suppress ads for those who subscribe. This adds a little complexity (and an annoyance to the free users) but it means the information would be available to all.
I'm sure these aren't the only way to do the trick that keeps us off the street. I welcome comments, suggestions, and brick-bats from Slashdotters.
Why not 'open source' the book as well? Part of the reason Heather and I didn't try to farm out the code analysis is that we wanted to have a consistent style. Frankly, it would be as much work to accept contributions and then edit them for style and structure as it would be to do the entire job ourselves. In one sense, the book will be open source in that readers will be able to post "yellow stickies" on our commentary...and readers can see the yellow-stickies (with attribution)."
-