>I want to be able to read a HUGE file without having such a negative
>impact on the system's buffer cache.
>
>I'm trying:
>
> if hasattr(os, 'O_DIRECT'):
> try:
> flags = fcntl.fcntl(sys.stdin.fileno(), fcntl.F_GETFL)
>
> flags
>Is there a way of setting O_DIRECT on a preexisting file like sys.stdin?
>
>Does C allow this sort of thing?
There is no O_DIRECT or fcntl() in Standard C.
fcntl() operates on an open file descriptor, and the file descriptor
for stdin is 0. Two calls to fcntl(), one with F_GETFL and one
with F_
>>>But HTML is not the problem!
>> Right, it's what the HTML-interpreting engines might do that is
>> the problem.
>
>You mean the same problem as for example using a very long header in
>your email to cause a buffer overflow? That is possible with plain
>ASCII, and has been done.
Before worryin
>> Does the language allow Javascript to open a new window? Does the
>> language allow Javascript to trigger a function when a window is
>> closed? I believe the answer to both questions is YES. Then it
>> is possible to have a page that pops up two windows whenever you
>> close one.
>
>This was
>Hello? I don't think that should make any difference. I should be able
>to visit absolutely any website on the Internet without any danger to my
>computer or the data stored on it. Any browser which allows otherwise
>has a bug.
Then Javascript *as a language* is a bug.
>Javascript is not inhere
>I would say by extrapolating the problem of spam and snooping that the
>next level of email software needs to concentrate on the following:
>
>1. routine and transparent encryption.
OK, but the Feds are really going to hate that.
>2. making spam no longer economic. Blocking all spam is, even in
>> Links
>> Javascript
>> Forms
>> References to other files
>
>the only piece of that particularly dangerous is JavaScript. So long
>as you have a scheme to unmask where links are really going links are
>no more dangerous than they are in browser.
Browsers don't read unsolici
>However, formatted text is not code.
HTML is much more than formatted text.
>Pictures are not code. It is
>unfair to tar them with the brush of JavaScript or the goofy things
>Outlook does with enclosures.
If you take all the dangerous stuff out of HTML, like:
Links
Javascript
>>And how do you fix the problem of unsolicited USENET articles?
>>(*ALL* of them are unsolicited to someone). Or unsolicited
>>email?
>
>Read my essay.
>http://mindprod.com/projects.html/mailreadernewsreader.html
>
>I talk around those problems.
>
>It requires a fresh start.
This URL does not
>>HTML enables a heck of a lot of problems: "web bugs" in email,
>>links to fake sites that appear as real ones in what shows up
>>on the screen, Javascript viruses, denial-of-service attacks
>>(pages that open two windows when you close one), etc.
>>
>>>That is like hating all choirs because tele
>>I think e-mail should be text only.
>
>I disagree. Your problem is spam, not HTML. Spam is associated with
>HTML and people have in Pavlovian fashion come to hate HTML.
>
>But HTML is not the problem!
HTML enables a heck of a lot of problems: "web bugs" in email,
links to fake sites that app
>The only thing I hate is when I am directed to some website that needs
>cookies, but doesn't tell me. A couple times I did a survey, wasting
>maybe 10 minutes of my life for a good cause, and then there was an
>error. Great! I guess that page needed cookies, but didn't bother to
>tell me. B
>>> HTML is designed to degrade gracefully (never mind that most web
>>> authors and many browser developers don't seem to comprehend this),
>>> so you don't really need a "subset" html to get the safety features
>>> you want. All you need to do is disable the appropriate features in
>>> the HTML r
>HTML is designed to degrade gracefully (never mind that most web
>authors and many browser developers don't seem to comprehend this), so
>you don't really need a "subset" html to get the safety features you
>want. All you need to do is disable the appropriate features in the
>HTML renderer in your
14 matches
Mail list logo
