Slashdot Mirror

I'd caution anyone against employing this mode of data transport in a production environment. Not only is latency high, but the RFC still has experimental status:

http://www.faqs.org/rfcs/rfc1149.html

I'd caution anyone against employing this mode of data transport in a production environment. Not only is latency high, but the RFC still has experimental status:

http://www.faqs.org/rfcs/rfc1149.html

--

Congress should order the Federal Communications Commission to create a nationwide list of people who do not wish to receive junk e-mail. Then it should target pornographers by making it a crime, with a $1,000-per-violation penalty, to send e-mail that advertises a sexually explicit Web site to any of those registered e-mail addresses. If this system works, it could then be expanded to other domains, such as "get rich quick" schemes and eventually to unsolicited advertisements of any kind.

Why is it bad? First of all, it legitimizes opt-out lists, which is what spammers want. Not only will they think they'll be free to send us their junk, it'll cost us. We'll still be in the same situation that we are in now.

Second, it doesn't address the potential of abuse hidden in unverified opt-in lists. To recap, verified opt-in lists send you an e-mail asking if you really want to subscribe to a list before actually subscribing. This is done no matter what method is used to subscribe. Unverified Opt-in just spams you in a haze wondering who the !)@)*#( signed you up.

Third, it doesn't address the best current practices as subscribed in the RFC's. There are many RFC's out there dealing with spam now. I suggest everyone read them. Faqs.Org has them.

There are better ways of success. Spread the word. Remain calm. Kill spam.

---
Another non-functioning site was "uncertainty.microsoft.com." The purpose of that site was not known. -- MSNBC 10-26-1999 on MS crack

Don't know if this will solve the problem but have you checked out mgetty?

http://www.faqs.org/faqs/fa x-faq/mgetty+sendfax+vgetty/

Even if "Apache" is bug free, how can you tell that the disk you got passed by your third cousin who got it from his ex-boss who got it from "some guy" is?

Welcome to the world of PGP/GPG/etc signatures for packages. It is entirely possible to get a verified version of whatever package you would like-- just go to the "official" FTP site or mirror, and download the source AND signature, and verify it. The official version usually has all the latest secuity patches integrated (maintainers know that these are critical fixes, and integrate them tout suite) and will typically be signed by some manner of digital signature.

Of course, this does open up the problem that you allude to that anyone can sign a package (provided they have a key pair), but the maintainers of any package that you need to use will likely be involved in the web of trust brought about through the key signing process. For more info, see the PGP FAQ's and look for information about key signing.

It would seem far more useful to me if source was "open" in the sense that you could get a copy of the code on production of a reasonable description of what you planned to do with it, what improvement you wanted to make, plus at least two references from people who were prepared to establish your bona fides. Kind of like the criteria for getting a reader's ticket to a law library.

The release version of any package is going to be pretty well checked over by the maintainer, and from a trusted source. The resisitance to the type of bureaucracy that you recommend is one of the best things about the OpenSource community.

Movie companies should have a site called something like movies.com where they put all their movies? (or just let people use imdb, which has links to movie homepage, IIRC)
#define X(x,y) x##y

for those of you who don't know what Goodwin's Law is check out: http://www.faqs.org/faqs/usenet/leg ends/godwin/

• Jolt 71.2mg
• Mountain Dew 55.0mg
• Coca-Cola 45.6mg

I've just finished reading the Infinite # of Monkeys Protocol Suite Request For Comments. Man, anybody who would spend that amount of time developing a suite of protocols to network . . . well, an infinite number of monkeys, is A+ certified in my books.

After reading it though, I thought of a few corrections which I thought may be of interest to all you other loyal slashdot readers.

The SIMIAN in the text, runs in to the problem of generating a Unique Value which identifies each of the infinite monkeys in the system. I've always thought that the Infinite Monkey idiom was really rooted more in the laws of Order & Chaos theory (Ya, I made that up). However, even a single monkey with an infinite amount of time would generate every text known to mankind, assuming mankind stopped producing texts sometime in the Finite future.

In fact, using the Infinite in a physical system is only good in terms of identifying its theoretical ability to expand. The KEEPER in the suite even identifies dead monkeys, which is useful, but we all know 1 dead monkey equals Infinity minus one, which is finite. Well, technically, it's an impossible equation.

I've come up with a better solution. An incredibly huge number of monkeys, working within a system which identifies there probability of creating already known texts, and there probability of creating good innovations to classical texts (Neo classical, hmmm).

The modified system makes use of a MOP identifier, or "Monkeys Over-all Performance", which works under two different layers of the system. A Per-Monkey MOP within each zoo calculates the performance of each monkey and relays the information back to a SYSTEM MOP which calculates both the overall performance of each ZOO, and generates the performance of the entire system.

A Probability of Innovative or Neo-Classical Text ID Organizer (or PINTO), would then make use of the very simple following equation to generate a time frame per monkey, per ZOO and per SYSTEM of each text being created in either an Innovative or Perfect way. Texts would be referenced from the GUTENBERG project.

Let A1 = (Character Output / Time) for Monkey
Let A2 = (Character Output / Time * Monkeys) for ZOO
Let A3 = (Character Output / Time * ZOO's) for System
Let B = Byte Size of each text to be produced
Let C = characters within language allowable
Let D = Average of CRITICS allowable word amount change to Neo-Classical ^ Words in a given language.
Let T represent Timed Probability Per Exact Text

T = (B^C / Ax)
Time Probability Per Innovative Texts = T / [1 + (B+D) + (B-D)]

The denominator for Timed Probability Per Innovative Text is actually just the total amount of different texts that would be allowed with variants. You can remove the 1 to omit the exact text.

Anybody see any problems? I'm thinking of submitting it.

Anyway, this system could have a definite market under some huge financial backing. Take Microsoft for example, they have a serious interest in developing readable material. I have books from the Microsoft Press which include, "Chess Strategies", "MCSE Exam Notes", and my personal favorite, "Writing Solid Code" written in the late 80s or early 90s by one of MS's top developers . . .

Come to think of it... Microsoft must already use a system like this.

A quick search of the rfc archives turn up several:

The first one I can find is RFC748, from 1978.

My favourites are RFC1217 - Memo from the Consortium for Slow Commotion Research, which "uses a highly redundant optical communication technique to achieve ultra-low, ultra-robust transmission. The basic unit is the M1A1 tank. Each tank is labelled with the number 0 or 1 painted four feet high on the tank turret in yellow, day-glo luminescent paint.", and RFC2549, IP over Avian Carriers with Quality of Service, which extends RFC1149 - "Encapsulation may be done with saran wrappers. Unintentional encapsulation in hawks has been known to occur, with decapsulation being messy and the packets mangled."

Anyone know how/why this started?

A quick search of the rfc archives turn up several:

The first one I can find is RFC748, from 1978.

My favourites are RFC1217 - Memo from the Consortium for Slow Commotion Research, which "uses a highly redundant optical communication technique to achieve ultra-low, ultra-robust transmission. The basic unit is the M1A1 tank. Each tank is labelled with the number 0 or 1 painted four feet high on the tank turret in yellow, day-glo luminescent paint.", and RFC2549, IP over Avian Carriers with Quality of Service, which extends RFC1149 - "Encapsulation may be done with saran wrappers. Unintentional encapsulation in hawks has been known to occur, with decapsulation being messy and the packets mangled."

Anyone know how/why this started?

A quick search of the rfc archives turn up several:

The first one I can find is RFC748, from 1978.

My favourites are RFC1217 - Memo from the Consortium for Slow Commotion Research, which "uses a highly redundant optical communication technique to achieve ultra-low, ultra-robust transmission. The basic unit is the M1A1 tank. Each tank is labelled with the number 0 or 1 painted four feet high on the tank turret in yellow, day-glo luminescent paint.", and RFC2549, IP over Avian Carriers with Quality of Service, which extends RFC1149 - "Encapsulation may be done with saran wrappers. Unintentional encapsulation in hawks has been known to occur, with decapsulation being messy and the packets mangled."

Anyone know how/why this started?

A quick search of the rfc archives turn up several:

The first one I can find is RFC748, from 1978.

My favourites are RFC1217 - Memo from the Consortium for Slow Commotion Research, which "uses a highly redundant optical communication technique to achieve ultra-low, ultra-robust transmission. The basic unit is the M1A1 tank. Each tank is labelled with the number 0 or 1 painted four feet high on the tank turret in yellow, day-glo luminescent paint.", and RFC2549, IP over Avian Carriers with Quality of Service, which extends RFC1149 - "Encapsulation may be done with saran wrappers. Unintentional encapsulation in hawks has been known to occur, with decapsulation being messy and the packets mangled."

Anyone know how/why this started?

I followed some of the links in the article, and it turns out this is actually an implementation of RFC 1907, TELNET SUBLIMINAL-MESSAGE Option

They didn't explicitly state it in the article, but having done research into telnet to write my own I/O driver I came across that option, and I couldn't figure out how to get it to work, so I just sent back Telnet WON'T and telnet DON'T. The system works by sending byte 255 'TELNET-IAC' (interpret as command) and then a 257 (subliminal message option). And then subliminal message code.

If this is the case, that means the CCA/MPAA has code the first full implementation of telnet, perhaps some prodigious hacker can reverse engineer there code again to find out how they did it. Everyone has been complaining about 'out of range data' (whatever that's supposed to mean). But I felt deep down that it was BS, I mean, why would they put it in the spec if no one knew how to use it?

If you just want time tracking software, check out this site and this one.

Good luck!

Well I don't have a copy of the standard, but my fragment compiles without warnings on gcc 2.95.2 using the -pedantic option.

Trusting GCC to reliably catch all violations of the standard is unwise. -pedantic is not really about catching coding errors, anyway. You really want some kind of -W option to catch this and, yes, it should ideally be on by default.

Since that's meant to make gcc complain about non-ANSI (i.e. ISO) extensions, does that mean this is a bug in gcc?

It means GCC doesn't catch this sort of bug for you by default. Maybe it would if you specified -Wall -W -O2 or something.

Are you sure it hasn't been added to the standard since the version you've seen?

No, because I don't track the standardization efforts (not even of C) closely. We're not talking about a "feature" so much as a detailed rule of behavior, designed to allow certain optimizations to take place. C is not Java; it does not mandate many sorts of ordering of things like side effects, the result being various things are left undefined. "Undefined" means not valid C code.

Would you care to provide a reference saying where in the ISO standard I should look to see what you're saying?

I believe I gave the basics of a good reference -- section 3.3 "Expressions", which might be numbered or even titled differently since 1988-12-07.

But = also does not define a sequence point, so by that argument "a=b=c=d=2" is also undefined. What am I missing here?

Nothing, if any of a, b, c, d refer to the same storage. Assuming they don't, though, which is likely what you mean to do, then what you're missing is that the sample statement does not violate this wording: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression."

And, from an anoncwrd:

Burley, you know lots about fortran but your wrong, the operators cant be evaluated in the wrong order, they use the return value of the next operator in.

First, I really know only FORTRAN 77 well, and that as an implementor, not a user. I know far more about ISO C than I do the present Fortran standard (95). (Which doesn't say much, I'll admit.)

Second, I wasn't objecting to evaluation order, but to the assumption of modification order in the original code.

A statement like "b += b += 2;" has only two pertinent sequence points, the one prior to the beginning of the execution of the statement, and the one at the end. There are no sequence points within the expression itself.

Now, y'all are right that "b += 2" must be evaluated before the rest of the expression.

But you're wrong in assuming the result of this evaluation is anything more than as if "b + 2" had been written instead.

Since there's another (outer) b += ... in the same expression, the C standard (draft copy I have anyway) says the expression is undefined. (I.e. it specifies conditions for the expression such that it is defined, and the statement in question violates those conditions, therefore it is not defined according to the standard.)

From a technical, practical-implementation point of view, the expression could be implemented (compiled as) "tmp2 = b + (tmp1 = b + 2);" with the following side-effects specified:

b = tmp1;
b = tmp2;

Specifically, the order in which those two assignments, vis-a-vis the evaluation of the expression, happen is unspecified, and an implementation could choose any order at any time, assuming it meets the obvious def-use ordering (i.e. tmp N must be defined before it can be referenced). You can't assume the b = tmp1; modification happens before the tmp2 = b + ... evaluation, for example.

So, you can't rely on the inner assignment to b being completed (i.e. the modification of b itself as a side effect) before the subsequent reference to it as part of the outer "b += ..." operation. So it might have the old value or, strictly speaking, any other value, or start World War III, or whatever.

a=a++ is not undefined. The a++ has to be evaluated first because the a is assigned the return value of the a++.

It is undefined, according to my draft copy, because a gets modified twice, not once, between the two sequence points. a=(a++,a) fixes that, I think, since there's now a sequence point between the two modifications.

You might say "but the same value gets written to a regardless of whether the a= or a++ modification happens first", and I'd agree with that, but the wording in the standard does not make a distinction between multiple modifications of an object with the same value versus with different values.

So, you might get away with it on more implementations (compilers, machines, etc.), and that's all nice and well, but it isn't any more "defined" than the clever XOR-hack .sig.

BTW, read also the wording under "Assignment operators". In my draft copy it says "The side effect of updating the stored value of the left operand shall occur between the previous and the next sequence point." Y'all are assuming it occurs between the evaluation of the assignment operator and the evaluation of any lower-precedence (outer) operator -- but it doesn't, it might occur later than that.

Finally, hey, couldn't y'all just read the comp.lang.c FAQ? I just pulled it up in no time, and questions around 3.3 seem to pretty succinctly say what I've been saying more long-windedly.

P.S. I'm clicking "No Score +1 Bonus" again on my post. It seems like canonical /. practice to do so in cases like this (off-topic posts).

Here is why...

ksh owns you all ;-)

Montgomery's short "An Introduction to Unix" points at the Unix system family tree.

That 1997 document does not mention Linux, which grew out of the POSIX definition, System V, NetBSD, and GNU tools (developed on many Unix flavors). The Unix History segment of the Unix FAQ does mention Linux briefly.

If I've got this right, this shows an abysmal lack of understanding of how routing actually works. See, IP packets have an "envelope" and a payload (the content). The envelope contains the source and destination addresses and ports ("From: 123.45.678.90:12345, To: 234.87.53.309:80"). It also contains some information destined to be used at the other end, such as whether the packet was fragmented along the way and which fragment # this one contains so that the original information can be reconstructed at the receiving end.

The "payload" of the packet is the content; what's inside the envelope. This is where all the data is put, including the HTTP "GET" requests. When you fetch a web page, your browser sends something like the following inside an IP packet:

HTTP/1.1 GET http://slashdot.org/

(There's more to it; read RFC 2616 to learn all about the HTTP/1.1 protocol). The point is that this is *inside* the packet. How are you going to tell which packets contain HTTP GET requests, huh? Look inside every packet? Sorry, buddy, not gonna do it. That would slow down ping times by at least a factor of ten: instead of 100-200ms, you'd have ping times of one or two seconds. For every communication.

Or maybe you just look inside packets with a destination port of 80? Yeah, that'd work, right? Nope -- web servers can run on any port. You'd immediately see lots of web servers hanging off port 8080, 8088, or even weird port numbers, serving up MP3's with unfiltered impunity.

There are a lot more reasons (which I won't go into) as to why this thing won't work as suggested. Thought exercise: where are the blocking lists going to live? And how will they be updated? Turn in a 500-1000 word essay to my desk by Monday for extra credit. :-)

Not to say that SOME kind of required-filtering law may be passed in Germany, but this isn't going to be it. If this gets passed, it will either (a) be utterly useless, or (b) slow down ALL Internet usage in Germany so much that the law would get repealed in record time as the German legislation realizes that it just cut its entire country off from the Internet.

I'm sure there are some factual errors in the above, as I whipped it out with virtually no research whatsoever. But the technical details of how routing works are pretty much as described. For the full story about IP and how it works, read RFC 791. For more about HTTP version 1.1, see the link several paragraphs above.
-----
The real meaning of the GNU GPL:

If I've got this right, this shows an abysmal lack of understanding of how routing actually works. See, IP packets have an "envelope" and a payload (the content). The envelope contains the source and destination addresses and ports ("From: 123.45.678.90:12345, To: 234.87.53.309:80"). It also contains some information destined to be used at the other end, such as whether the packet was fragmented along the way and which fragment # this one contains so that the original information can be reconstructed at the receiving end.

The "payload" of the packet is the content; what's inside the envelope. This is where all the data is put, including the HTTP "GET" requests. When you fetch a web page, your browser sends something like the following inside an IP packet:

HTTP/1.1 GET http://slashdot.org/

(There's more to it; read RFC 2616 to learn all about the HTTP/1.1 protocol). The point is that this is *inside* the packet. How are you going to tell which packets contain HTTP GET requests, huh? Look inside every packet? Sorry, buddy, not gonna do it. That would slow down ping times by at least a factor of ten: instead of 100-200ms, you'd have ping times of one or two seconds. For every communication.

Or maybe you just look inside packets with a destination port of 80? Yeah, that'd work, right? Nope -- web servers can run on any port. You'd immediately see lots of web servers hanging off port 8080, 8088, or even weird port numbers, serving up MP3's with unfiltered impunity.

There are a lot more reasons (which I won't go into) as to why this thing won't work as suggested. Thought exercise: where are the blocking lists going to live? And how will they be updated? Turn in a 500-1000 word essay to my desk by Monday for extra credit. :-)

Not to say that SOME kind of required-filtering law may be passed in Germany, but this isn't going to be it. If this gets passed, it will either (a) be utterly useless, or (b) slow down ALL Internet usage in Germany so much that the law would get repealed in record time as the German legislation realizes that it just cut its entire country off from the Internet.

I'm sure there are some factual errors in the above, as I whipped it out with virtually no research whatsoever. But the technical details of how routing works are pretty much as described. For the full story about IP and how it works, read RFC 791. For more about HTTP version 1.1, see the link several paragraphs above.
-----
The real meaning of the GNU GPL:

Montgomery's short "An Introduction to Unix" points at the Unix system family tree.

That 1997 document does not mention Linux, which grew out of the POSIX definition, System V, NetBSD, and GNU tools (developed on many Unix flavors). The Unix History segment of the Unix FAQ does mention Linux briefly.

you can read it online, if every server put these informations in their configuration, it can also helps traceroute problems etc
--
BeDevId 15453
Download BeOS R5 Lite free!

The RLE compression patent to which Gailly refers is "4056828: Run length encoding and decoding methods and means", filed by - you guessed it - Xerox.

The comp.compression FAQ, which Gailly maintains, mentions patent 4,586,027 as "[covering] run-length encoding in its most primitive form."

The good news is that the FAQ is incorrect. Patent 4,586,027 does not cover RLE as such, but a variant in which the run length is placed before and after the compressed run. This allows the decompressor to read the stream backwards, as from a magnetic tape, and still correctly decompress the stream. All of the independent claims make some mention of "front and back" or "front and end."

Moreover, this patent expired in 1998 for nonpayment of maintenance fees.

Who are "they" ?
.: "They" are the OpenBSD core team represented by Theo de Raadt.

What's this document about ?
.: I received a lot of request to tell my side of the story, since it's impossible to reply to all people in detail, I decided to setup this page to answer the most common questions.

Why did you register openssh.org ?
.: The company I work part-time for allowed me to investigate the kickstart of a open/free ssh server client combo that was compatible with ssh1 and could run on Linux/Solaris.

The project title was, guess what ... 'openssh' ...

I learned from LWN that there was an other group working on an openssh version so I contacted Theo de Raadt and asked if he was interested in developing a port for Linux/Solaris. He told me that they were only interested in developing a version for OpenBSD.

I registered openssh.org and was trying to find someone to do the porting. Unrelated to my activities Damien Miller started a succesful porting effort for Linux/Solaris, so there was no necessety for my search to continue.

Why didn't you give away openssh.org to openbsd ?
.: Actually I tried. I mailed Theo de Raadt and told him I was willing to give control of the opensh.org to them provided they added links to other open/free ssh projects on 'their openssh.org' page.

Then why do you still have openssh.org?
.: Theo de Raadt first agreed and suggested I register http://www.freessh.org, which I promptly did, but later he canceled the deal telling me:
"We're not going to get ripped off by someone we don't trust".

What happend then (part 1) ?
.: Theo sent me some nasty emails and I didn't hear from him again untill the 1st of March. I offered other openssh developers the use of www,cvs,ftp and mail, but they declined. As a service to the community I rewrote the openssh.org URL to openssh.com so people would be transfered to that domain automaticly.

What happend then (part 2) ?
.: Theo sent me an email demanding I remove the mx records for openssh.org. Theo must have known this demand was impossible since rfc822 requires that postmaster@domain is a valid email address. Without mx this is not the case, and I would violate this requirement.

We exchanged some email about/with the word please and we summarized the November email exchange.

And then ?
.: Theo sent me a message telling me he would post a banner on openssh.com to warn people, he would post a message to BUGTRAQ and there would be story on slashdot.org. Handing over the domain would stop that.

So what did you do ?
.: Nothing, I was surprised someone was trying to coerce me.

Did other people contact you ?
.: I received a sudden influx of messages most cc'ed to openssh@openssh.com requesting me to hand over openssh.org, some seemed to believe I was reading their mail, while others were angry they couldn't receive mail @openssh.org. Since I offered the use of www,cvs,ftp and mail to the openssh developers this strikes me as strange.

How is mail for openssh.org setup than ?
.: It's a virtual host that only accepts mail for postmaster@openssh.org, root@openssh.org, webmaster@openssh.org, all other mail will bounce. Since the mx points to the same host that used to run the remailer@replay.com, and still runs the remailer@hr13.zedz.net, sendmail is setup with 'LOGLEVEL=0', so not only do I not receive bounced mails, I don't even get a logfile of people who tried to send mail.

What do you think of the OpenBSD Announcement ?
.: They recommend caution since "there could be privacy issues, possibly data mining or building a mailing list of security conscious users". I feel this was sent 'in the spur of the moment'. If I wanted a to build a mailinglist of security conscious users or was dataming, the only thing I would have to do is mail all the users of the ZedZ ftp-site. As for the privacy issues, I've provided and still provide ways to anonymously access the Internet. But you decide.

Why do I suddenly get a seperate page at openssh.org ?
.: Damien Miller laid out his concerns about the seamless redirect from the openssh.org URL to the openbsd.com URL and requested me to remove the rewrite and to setup a seperate page. Which I did.

What happens next ?
.: I'm disappointed in the behaviour of one or two people but since my main goal is and always will be the spread of encryption products and the use of those products by end users, hence the building of the ZedZ ftp site, I'm willing to 'get over' that.

In order to facilitate the community I suggest to the OpenSSH/OpenBSD group that they supply me with a zone file and a secondary for openssh.org. I will instruct the primary DNS to fetch the zone file from the OpenSSH controlled secondary. It's up to the OpenSSH/OpenBSD group to configure the layout of the domain. If at a later stage 'the wounds' are healed and a mutual understanding, maybe even a mutual appreciation has been reached it's not impossible that the domain will be donated to the OpenSSH Project.

Since OpenBSD already uses ftp.zedz.net as primary ftp site for rsaref and cfs for instance (under it's old name utopia.hacktic.nl) this seems a reasonable and acceptable compromise to me.

Other whishes ?
.: A public apology from Theo would be nice. Also the OpenSSH.com site is very OpenBSD centric a change that would level the exposure of other OS's would be welcomed, but it's up to their webteam to decide.

Other things ?
.: Not at the moment.

How can I contact you ?
.: Just mail me at adejoode@zedz.net

Exit! Stage Left!

Wrong. It was 64 bit. From Atari Jaguar Frequently Asked Questions:

The Jaguar has five processors which are contained in three chips. Two of
the chips are proprietary designs, nicknamed "Tom" and "Jerry". The third
chip is a standard Motorola 68000, and used as a coprocessor. Tom and
Jerry are built using an 0.5 micron silicon process. With proper
programming, all five processors can run in parallel.

- "Tom"
- 750,000 transistors, 208 pins
- Graphics Processing Unit (processor #1)
- 32-bit RISC architecture (32/64 processor)
- 64 registers of 32 bits wide
- Has access to all 64 bits of the system bus
- Can read 64 bits of data in one instruction
- Rated at 26.591 MIPS (million instructions per second)
- Runs at 26.591 MHz
- 4K bytes of zero wait-state internal SRAM
- Performs a wide range of high-speed graphic effects
- Programmable
- Object processor (processor #2)
- 64-bit RISC architecture
- 64-bit wide registers
- Programmable processor that can act as a variety of different video
architectures, such as a sprite engine, a pixel-mapped display, a
character-mapped system, and others.
- Blitter (processor #3)
- 64-bit RISC architecture
- 64-bit wide registers
- Performs high-speed logical operations
- Hardware support for Z-buffering and Gouraud shading
- DRAM memory controller
- 64 bits
- Accesses the DRAM directly

- "Jerry"
- 600,000 transistors, 144 pins
- Digital Signal Processor (processor #4)
- 32 bits (32-bit registers)
- Rated at 26.6 MIPS (million instructions per second)
- Runs at 26.6 MHz
- Same RISC core as the Graphics Processing Unit
- Not limited to sound generation
- 8K bytes of zero wait-state internal SRAM
- CD-quality sound (16-bit stereo)
- Number of sound channels limited by software
- Two DACs (stereo) convert digital data to analog sound signals
- Full stereo capabilities
- Wavetable synthesis, FM synthesis, FM Sample synthesis, and AM
synthesis
- A clock control block, incorporating timers, and a UART
- Joystick control

- Motorola 68000 (processor #5)
- Runs at 13.295MHz
- General purpose control processor

Communication is performed with a high speed 64-bit data bus, rated at
106.364 megabytes/second. The 68000 is only able to access 16 bits of this
bus at a time.

The Jaguar contains two megabytes (16 megabits) of fast page-mode DRAM,
in four chips with 512 K each. Game cartridges can support up to six
megabytes (48 megabits) of information, and can contain an EEPROM
(electrically erasable/programmable read-only memory) chip to save game
information and settings. Up to 100,000 writes can be performed with the
EEPROM; after that, future writes may not be saved (performance varies
widely, but 100,000 is a guaranteed minimum). Depending on use, this limit
should take from 10 to 50 years to reach.

The Jaguar uses 24-bit addressing, and is reportedly capable of accessing
data as follows:

Six megabytes cartridge ROM
Eight megabytes DRAM
Two megabytes miscellaneous/expansion

All of the processors can access the main DRAM memory area directly. The
Digital Signal Processor and the Graphics Processor can execute code out of
either their internal caches, or out of main memory. The only limitations
are that

I hate to reply to my own post, but I managed to dig up the comp.os.unix.shell FAQ posting on shell comparisons: here.

Definetely worth a look for those shopping for a shell...

engineers never lie; we just approximate the truth.

Yes, Eiffel.
--
Patrick Doyle

WHAT HAPPENED TO THE SATURN V PLANS

"Despite a widespread belief to the contrary, the Saturn V blueprints have not been lost. They are kept at Marshall Space Flight Center on microfilm.

The problem in re-creating the Saturn V is not finding the drawings, it is finding vendors who can supply mid-1960's vintage hardware (like guidance system components), and the fact that the launch pads and VAB have been converted to Space Shuttle use, so you have no place to launch from.

By the time you redesign to accommodate available hardware and re-modify the launch pads, you may as well have started from scratch with a clean sheet design."

Kean

We were having difficulty with the standards committee controlling the North American Presentation Level Protocol Syntax -- the graphics protocol upon which the Viewtron videotex terminals built by Western Electric were based. Specifically, there wasn't enough programmability. The Western Electric terminal was so limited in capacity that we had to fit the graphics interpreter into a very few number of bytes, and could afford only a few thousand bytes of dynamically downloadable store. I had been enamored with Forth ever since the Byte magazine article about it about a year or so earlier (my first digital purchase was an HP35 so reverse polish didn't bother me perhaps as much as it should have). Even so, I was hunting around for options. Jim Thompson, another senior staff member with the Viewtron project, was also interested in Forth -- enough so that he had subscribed to the Forth newsletter, which he shared with me. Jim was supposed to develop a menu system to run on the central system. I had specifically asked that his menu system never achieve Turing Machine equivalence, because I knew what sort of horrors lay in wait for us if it did. Nevertheless, Jim eventually implemented GOLFBAL "Game Oriented Language for Business And Leisure" -- and it was a Forth derivative. I had rejected Forth as anything but the low level protocol and engine for the telesoftware graphics system and was fairly horrified to discover what he had done. In any case, it was this immersion in Forth we brought with us to our meeting with the Xerox PARC folks.

Now, I swear on a stack of bibles that after I met with the PARC folks and discussed the problems of graphics communications, I had no idea the industry could end up being stuck with Postscript as a type-setting standard. I can say this for a certainty because:

I wanted to see a Novix-style reduction-to-hardware of the Forth virtual machine so that Forth would become the macro assembly language. Then we could use the Forth silicon machine to start running dynamically downloaded Smalltalk -- or some similar high level language -- compiled for the Forth stack machine which would provide much more powerful graphics specifications than Forth itself.

I never imagined the Smalltalk guys would actually depart from Smalltalk itself as a graphical specification language.

By the time the PARC guys spun off Adobe with Postscript and its Forth-like engine, I had become more interested in constraint/relational programming semantics than object oriented semantics because it more naturally fits graphics description, distribution, nondeterminism and parallelism not to mention databases.

It was summer of 1982 when I met with Tesler for the last time -- and he had just left PARC to go work on Lisa. We were sitting in the empty Astrodome, I think it was, next to the convention center where the Commodore 64 was being introduced to the world market as part of the precursor to Comdex. 64K of memory! At any rate, Tesler and I discussed the reason he had abandoned Smalltalk for the Lisa. I had thought that type inference coupled with artful use of assembly language libraries would be sufficient on the Motorola 68000 family, but Tesler was insistent that Object Pascal was necessary for adequate speed. Frankly, I was apalled that Tesler had so easily abandoned Smalltalk with type inference since he had made specific mention of it as an optimization technique in his Byte article. But in a recent email exchange about this history, he told me type inference was never of much interest to him -- that others at Apple were hooked on Object Pascal.

The horrifying thing about all this is that when Steve Jobs took off from Apple to found NeXT, instead of correcting the nonsense with Postscript and going straight for Smalltalk with type inference, he repeated the mistake, only this time with Objective-C. Then, as I understand it, Objective-C was the precursor to Java with its reliance on declaration rather than inference for type checking. This despite the fact that Sun already had the Self programming language in house with type inference and dynamic optimization technologies that realized the potential of Smalltalk at along last. Unfortunately the only technology to make it bigtime from Sun's Self project was the Hotspot JVM.

Although these aren't exactly the same mistakes over and over, we're still struggling to get a decent, widely-used dynamically typed language "for everyone" that includes a pure OO library for graphics. Python isn't easily deployable and although I'm a Perl bigot, even I realize we're unlikely to get Perlscript installed in every browser anytime soon. Anyway I'm partial to prototype languages like Self when it comes to Smalltalk offspring. I do have hopes for TIBET as a way of turning Javascript into a powerful programming system across many platforms -- as outrageous as that sounds. I know Bill Edney and Scott Shattuck were some of the first NeXT hackers, but we can all pray for a swift recovery. This isn't an official announcement or anything -- but Bill and Scott did do a presentation at Hackers so I figure I can mention it in the mode of a "hot rumor".

As I said, I'm more into constraint/relational stuff these days myself, but it sure would be nice if someone brought the power originally in Smalltalk the ubiquity it deserved almost 20 years ago.

Also the LDP is generally approachable, you can join in on the ldp-discuss list, or perhaps first peruse the archive and make your suggestions. Even simpler is the automated feature where you can submit your own links

Well, I just looked at the LDP site and I have to say, it looks good. Very navigable, the search engine seems to work. I have to say, though, that I've never been a huge fan of the style that seems to be dominating these days: the page full of news-boxes with a itsy-bitsy nav bar on one side. Nevertheless, it works.

Though I'd hate to make more work for them, I might make one suggestion for the LDP. Since they're hosting just about everything else, what about incorporating a subject indexed RFC archive? It would be nice to be able to get all these things from one place, and the LDP could perhaps do a better job of sorting them than most (ie. preferentially return protocol specs over obscure derivaties of said protocols). I generally use the archive at faqs.org, but their search results are a real pain to wade through.

Just a thought.

Fact is, the internet as it stands evolved from the ARPAnet. As a military network, this was designed with security and resilience in mind. No military funded project can avoid the obsession with security and secrecy.

If you don't agree, can you tell me then, what the security bits in the IP header are there for ?

Please read RFC 1108 and think about what it says before replying.

Is it to promote openness ? Or could it be that TCP/IP was designed for military application, and therefore has a form of security built in from the start.

Are you prepared to read what you wrote, and re-evaluate the statement you made ?

The RFCs are out there and available to anyone with an internet connection.

Extract from RFC 1108

9.3.15.3.2 Classification Protection Level.

This field specifies the U.S. classification level to which the datagram should be protected.

The information in the datagram should be assumed to be at this level until and unless it is

regraded in accordance with the procedures of all indicated protecting authorities. This field specifies one of the

four U.S. classification levels, and is encoded as follows:

11011110 - Top Secret

10101101 - Secret

01111010 - Confidential

01010101 - Unclassified

Or have I missed the point here ? Would you care to explain exactly how a classification of "Top Secret" makes a protocol "open and accessible" ?

The process of developing the protocols may well be open, but the fact remains that the protocols from very early on had a military security classification tag in the header, which persists to this day.

If you still disagree in the face of cold hard facts, it is safe to assume you do not wish to be held to the same standards of journalistic integrity that you would be held to in conventional media, and if that is the case, its not hard to see why you attract so many flames when posting to Slashdot posing as a serious journalist.

What kind of cheap $3 crack is Katz smoking ?

RFC 762 from 1980 would seem to suggest he is about as wrong as it is possible to be.

The following internet options are defined:

CLASS NUMBER LENGTH DESCRIPTION

----- ------ ------ -----------

0 0 - End of Option list. This option occupies only 1 octet; it has no length octet.

0 1 - No Operation. This option occupies only 1 octet; it has no length octet.

0 2 4 Security. Used to carry Security, and user group (TCC) information compatible with DOD requirements.

So it appears that Katz's assertion is in fact totally wrong, which makes one wonder about the quality of the rest of the article.

Obviously I didn't read any further than this totally obvious error, as my time is too valuable.

--

It was asked above how this compares with Citrix. The article mentions that Citrix has to tinker with MS Terminal Server, while this RDP interface is what is normally used by MS NT TS to talk to an "ultra-thin client" (MS term in above link).

Is USENET an acronym, or simply capitalized for emphasis. This didn't tell me. Thursday is Curiosity Day.

For the humor impaired, please click the link to get the joke.

From here (search for IBM)

# 2001: A Space Odyssey (1968)

Incrementing each letter of ``HAL'' gives you ''IBM''.
'Arthur C Clarke' (qv) (co-screenwriter) claimed this was unintentional, and if he had noticed it before it was too late, he would have changed it.

>And of course there's the matter of people making
>huge files available only by HTTP so that they're
>almost impossible to get over anything except a
>T1 or greater, and sometimes not even then.
>(There's no resume capability that I'm aware of.)

Hmmm...

Have a look at RFC 2616, "HTTP/1.1" and it's sections 3.12 (Range Units), 14.16 (Content-Range) and 14.35 (Range)...

Also, try wget for resuming HTTP downloads, or GetRight or something similar if you're running windows... hell, even Netscape resumes downloading if the connection over which you were downloading a pr0n picture gets disconnected... *nudgenudgewinkwink*, *grin*

(Score: -1, On-Topic)

np: Autechre - Basscadubmx (Basscad EP)

As always under permanent deconstruction.

Actually, only x.com is illegal, according to the relevant RFCs. RFC 1123 states:

The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.

So, 2600.org is perfectly fine.

RFC 952 states:

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. The first character must be an alpha character. The last character must not be a minus sign or period. Single character names or nicknames are not allowed.

So any length between two and twenty-four characters is okay, and hp.com is fine. How x.com was registered is beyond me, and serves as an illustration of how network solutions never really was very good at its job.

Actually, only x.com is illegal, according to the relevant RFCs. RFC 1123 states:

The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.

So, 2600.org is perfectly fine.

RFC 952 states:

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. The first character must be an alpha character. The last character must not be a minus sign or period. Single character names or nicknames are not allowed.

So any length between two and twenty-four characters is okay, and hp.com is fine. How x.com was registered is beyond me, and serves as an illustration of how network solutions never really was very good at its job.

Or what?

Have a look here: RFC2550: Y10K and beyond. Would not it be cool to say that my fave' os is Y10K compliant. (sp?)

This RFC is mostly humour oriented, but the solution it gives is worth thinking about. (197x Cobolhead would take the y2k bug also with humour...)

BTW: I do not know the visions of BSDers, but I recall that for Linus it is ok, that Linux is replaced by 'something better' in ~30 years... How much have I heard sayings like this?

(serious tone not intended)

"As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one."

-Mike Godwin

But see, you also forgot about Quirk's exception;

"Quirk's Exception: Intentional invocation of this so-called "Nazi Clause" is ineffectual."

Nice try though :-)

For more info, including how to properly invoke, use and skirt Godwin's law please see the Godwin's Law FAQ"


mcrandello@my-deja.com
rschaar{at}pegasus.cc.ucf.edu if it's important.

http://www.faqs.org/faqs/arch-storage/part2/sectio n-151.html (Very thorough and careful)

http://www.westerndigital.com/products/drives/driv ers-ed/mtbf.html (What Western Digital has to say about MTBF)

http://www.storage.ibm.com/storage/oem/tech/mtbf.h tm (What IBM has to say about MTBF)

--------------------

As an aside, this is an interesting example of the breakdown of moderation on Slashdot. Several people are posting fairly coherent and, at least, pseudo-technical explanations about the calculation of MTBF, but I wasn't able to resolve who was right. The moderation points did not help me either, because they are being assigned by random people I can't trust. I thought, "It is unlikely that very many people on Slashdot actually know how how MTBF is done," and, "It is unlikely that those who actually do know MTBF have the moderation points."

I'm by no means a Lisp expert (I have more experience hacking C and Perl), but the more Lisp code I write, the more I begin to appreciate the language. I started learning Lisp when I started using EMACS, then for a while I was hacking in Scheme (the Programming Language Concepts class at my alma mater was taught by a fellow who received his degree from Indiana University), and now I am doing a lot of programming (in my Copious Free Time) in Common Lisp - and I must say that of the three, I like Common Lisp the best.

Here's a short list of the things *I* like in Lisp (whither EMACS Lisp, Common Lisp, Scheme, Dylan, etc.):

• automatic memory management (aka "garbage collection")
• several excellent compilers available (ask about the difference between "interactive" and "interpreted" some time - those words are NOT synonyms)
• bignums and symbols
• CLOS (lots better than e.g. C++ or even Java, in my opinion), which has generic functions, multiple inheritance, CHANGE-CLASS, etc.
• continuations (only in Scheme, I think)
• "code as data and data as code"
• the macro facility

...and so forth. You can get a lot more information from the Association of Lisp Users web site (especially the pages Language Comparisons and What is Lisp?), or from the comp.lang.lisp FAQ. Another good place to get more information is from David Lamkins' on-line book Successful Lisp.

And if you have further questions on Lisp, feel free to send me an email or drop a note into comp.lang.lisp.

HTH.

3.Anyone have any idea how to fix the problem of dynamic IPs?

• Read Bill LeFebvre's article on Internet Black Holes to learn how the Real-Time Black Hole system uses DNS creatively. You can also go write to the source if you prefer. Here's an excerpt:

  The simplest way to get started using the MAPS RBL to protect your mail relay against theft of service by spammers is to arrange for it to make a DNS query (of a stylized name) whenever you receive an incoming mail message from a host whose spam status you do not know.

• Here's the abstract for TCP Splicing for Application Layer Proxy Performance, by Pravin Bhagwat et al.:

  Application layer proxies already play an important role in today's networks, serving as firewalls and HTTP caches -- and their role is being expanded to include encryption, compression, and mobility support services. Current application layer proxies suffer major performance penalties as they spend most of their time moving data back and forth between connections, context switching and crossing protection boundaries for each chunk of data they handle. We present a technique called TCP Splice that provides kernel support for data relaying operations which runs at near router speeds. In our lab testing, we find SOCKS firewalls using TCP Splice can sustain a data throughput twice that of normal firewalls, with an average packet forwarding latency 30 times less.

• Here's the abstract for Improving HTTP Caching Proxy Performance with TCP Tap:

  Application layer proxies are an extremely popular method for adding new services to existing network applications. They provide backwards compatibility, centralized administration, and the convenience of the application layer programming environment. Since proxies act as traffic concentrators, serving multiple clients at the same time, during peak load periods they often become performance bottlenecks. In this paper we present an extension of the TCP Splice technique called TCP Tap that promises to dramatically improve the performance of a HTTP caching proxy, just as TCP Splice doubled the throughput of an application layer firewall proxy.

• Cohen, A., S. Rangarajan, and H. Slye. On the Performance of TCP Splicing for URL-aware Redirection. In: Proceedings of the USENIX Symposium on Internet Technologies and Systems, pp. 117-125, October 1999.

  Recently, the focus of the work on NEPPI applications was mostly on high performance URL-aware switching using TCP splicing. TCP splicing is a technique for bridging TCP connections at the IP level within the kernel, thus avoiding the overhead of application-level copying between sockets as performed by programs such as proxies. URL-aware switching with TCP splicing can be utilized in layer 7 switches to achieve high performance content-aware redirection of HTTP requests. We have developed of prototype of a layer 4/7 switch based on NEPPI.

• A Mobile Networking System based on Internet Protocol(IP) Pravin Bhagwat, Charles Perkins. Proceedings of USENIX Symposium on Mobile and Location Independent Computing, August, 1993, Cambridge, MA.

  Due to advances in wireless communication technology there is a growing demand for providing continuous network access to the users of portable computers, regardless of their location. Existing network protocols cannot meet this requirement since they were designed with the assumption of a static network topology where hosts do not change their location over time. Based on IP's Loose Source Route option, we have developed a scheme for providing transparent network access to mobile hosts. Our scheme is easy to implement, requires no changes to the existing set of hosts and routers, and achieves optimal routing in most cases. An outline of the proposed scheme is presented and a reference implementation is described.

• A Mobile Host Protocol Supporting Route Optimization and Authentication IEEE Journal on Selected Areas in Communications, special issue on "Mobile and Wireless Computing Networks," 13(5):839-849, June 1995. c IEEE. Andrew Myles Department of Electronics

  Host mobility is becoming an important issue due to the recent proliferation of notebook and palmtop computers, the development of wireless network interfaces, and the growth in global internetworking. This paper describes the design and implementation of a mobile host protocol, called the Internet Mobile Host Protocol (IMHP), that is compatible with the TCP/IP protocol suite, and allows a mobile host to move around the Internet without changing its identity. In particular, IMHP provides host mobility over both the local and wide area, while remaining transparent to the user and to other hosts communicating with the mobile host. IMHP features route optimization and integrated authentication of all management packets. Route optimization allows a node to cache the location of a mobile host and to send future packets directly to that mobile host. By authenticating all management packets, IMHP guards against possible attacks on packet routing to mobile hosts, including the interception or ...

• RFC 2230 has some words that might be relevant here:

  Dial-Up Host Example

  This example outlines a possible use of KX records with mobile hosts that dial into the network via PPP and are dynamically assigned an IP address and domain-name at dial-in time.

  Consider the situation where each mobile node is dynamically assigned both a domain name and an IP address at the time that node dials into the network. Let the policy require that each mobile node act as its own Key Exchanger. In this case, it is important that dial-in nodes use addresses from one or more well known IP subnets or address pools dedicated to dial-in access. If that is true, then no KX record or other action is needed to ensure that each node will act as its own Key Exchanger because lack of a KX record indicates that the node is its own Key Exchanger.

  Consider the situation where the mobile node's domain name remains constant but its IP address changes. Let the policy require that each mobile node act as its own Key Exchanger. In this case, there might be operational problems when another node attempts to perform a secure reverse DNS lookup on the IP address to determine the corresponding domain name. The authenticated DNS binding (in the form of a PTR record) between the mobile node's currently assigned IP address and its permanent domain name will need to be securely updated each time the node is assigned a new IP address. There are no mechanisms for accomplishing this that are both IETF-standard and widely deployed as of the time this note was written. Use of Dynamic

  DNS Update without authentication is a significant security risk and hence is not recommended for this situation.

Actually, the Y10K bug has already been solved; read RFC2550 for details.

Yeah, those things are BITCHIN!

The one draw back is they remind me a little of the nasty white ball thing in THE PRISONER that hunt you down if you try to leave the island. That thing gave me many nightmares!

I had occasion to do this with an old 19" mono Vax monitor and a 21" IBM 6091. Both served me well, but the lack of console-mode eventually drove me to abandon them. The hardest part will be finding specific specs on your monitors so you can compute the dot clocks. Here are two useful links on the subject. http://www.faqs.org/faqs/pc-har dware-faq/video/part4/ http://www.mindspring.com/~nunez/info /monitor