Slashdot Mirror

If the FCC suddenly said one day ok, people have to be able to take their IPs with them. ISPs would be pissed, but they'd probably all move to IP6 where its much more possible.

This was an April 1st RFC (RFC2250)

One of the claims in their oldest patent, 5132992, is:

"1. A transmission system for providing information to be transmitted to remote locations, the transmission system comprising:
library means for storing items containing information; identification encoding means for retrieving the information in the items from the library means and for assigning a unique identification code to the retrieved information;
conversion means, coupled to the identification encoding means, for placing the retrieved information into a predetermined format as formatted data;
ordering means, coupled to the conversion means, for placing the formatted data into a sequence of addressable data blocks;
compression means, coupled to the ordering means, for compressing the formatted and sequenced data blocks;
compressed data storing means, coupled to the data compression means, for storing as files the compressed, sequenced data blocks received from the data compression means with the unique identification code assigned by the identification encoding means; and
transmitter means, coupled to the compressed data storing means, for sending at least a portion of one of the files to one of the remote locations."

From this description, it sounds like web, ftp and gopher servers fall under the patent. However, I would think that, since the method that is described was first published in 1971 in RFC 114, 21 years BEFORE the this patent was filed, this patent would be disqualified via the prior art argument.

As for the other patents, you can find their IP list here and the USPTO patent search engine here. Have fun.

His insight that Domain Naming services tie it all together is quite important. Despite what you think.

You may very well be correct. That is one approach to locating services on the internet: Know the name of the service a priori. Curiously, it is also precisely the approach that Microsoft took with Active Directory.

There are other approaches, however. The world's oldest and largest directory provider, Novell, bet the farm on the Service Location Protocl, or SLP. Sun & IBM are also very prominent in the SLP community [as well as the closely aligned Project Liberty initiative].

Bottom line: There are multiple, competing approaches to the problem of finding resources on the internet. Heck, when you get right down to it, there's nothing wrong with the old Altavista PeopleSearch. Over time, one of these initiatives will win the greatest market share, and all of the survivors will almost certainly become "compatible" to some extent or another. And it may very well be that Microsoft's approach [DynDNS in conjunction with Kerberos] will be the winner. But there's been an awful lot of resistance to Redmond thus far, and their Passport initiative has, to date, been just shy of an utter and complete disaster.

However, there are two enormous stumbling blocks to further adoption of DNS: Classically, it is an unencrypted protocol with no proper sense of authentication whatsoever. If it is to move forward, the industry will have to move towards encrypted, authenticatible versions of it.

The second stumbling block is much more ominous, however: Against what database [i.e. directory] is DNS to be authenticated? Who will hold the master keys to the server-side authentication and who will hold the master keys to the client-side authentication? Once you require authentication, you give up every ounce of your anonymity on the internet. [Obviously Project Liberty suffers from the same fundamental flaw.] Once you lose anonymity, Big Brother knows who you are, where you are, and precisely what you are doing for the remainder of your life on the web.

Now you could argue that the telecomms already have that power over you when it comes to classical POTS, and that a court order [or "warrant"] is required for the telecomms to release your telephone dialing history, but in all truth: How many times have you used classical POTS to post a political tirade anonymously on a web bulletin board? Or download some pr0n, or place an off-shore bet on a sports team, or purchase a nice Mosel riesling from Wine Commune?

There are THREE main standards:

SIP, H.323, and MGCP
-n

``It handles most NATs correctly (using STUN).''

I always thought the most obvious solution to connecting to a NATed node is to have the NAT box act as a relay to the nodes it performs NAT for. One way to implement this (without running out of address/port pairs) is to use IP-IP tunneling. This is described, for example, in RFC 2003).

Nodes can then negotiate (or, with an extension to DNS, look up) the parameters to use to traverse all the NAT boxen in between them. This schema doesn't require traffic to go through a server it would not otherwise pass through. The cost is one additional IP header per anti-NAT traversal.

for those who don't know what SIP is.

A number of years ago, the telecom providers got together and tried to do VoIP. They came up with H.323, which was a terrible mess and near impossible to do anything with. To top that off, you have to pay for access to the spec (I'm only pretty sure about this, please correct me if I'm wrong) So VoIP didn't go anywhere for a while.

Then the IP folks (the people who designed the internet protocols like IP, TCP, UDP, etc) came together and designed SIP. The entire protocol is described in a mere 150 page RFC. Anyone who's implemented a standardized protocol from a spec knows what a godsend a short spec is.

In short, SIP is a protocol designed by the Internet folks for the Internet. It's layered on RTP, so the audio quality degrades gracefully with the link quality. You can operate it point-to-point by simply running two clients on two machines and pointing one at the other's IP address. Or, if you want an easy to remember URL, you can sign up for a free account at places like fwd.pulver.net. You'll then be accessible as sip:username@fwd.pulver.net.

Google for "SIP softphones" and you'll find quit a few clients. The big ones on linux are kphone and linphone. Shtoom is making some headway also, and runs on linux, windows, and os x.

Skype decided they don't like either H.323 or SIP, went off and designed their own proprietary protocol, and is keeping it secret from everyone else.

for those who don't know what SIP is.

A number of years ago, the telecom providers got together and tried to do VoIP. They came up with H.323, which was a terrible mess and near impossible to do anything with. To top that off, you have to pay for access to the spec (I'm only pretty sure about this, please correct me if I'm wrong) So VoIP didn't go anywhere for a while.

Then the IP folks (the people who designed the internet protocols like IP, TCP, UDP, etc) came together and designed SIP. The entire protocol is described in a mere 150 page RFC. Anyone who's implemented a standardized protocol from a spec knows what a godsend a short spec is.

In short, SIP is a protocol designed by the Internet folks for the Internet. It's layered on RTP, so the audio quality degrades gracefully with the link quality. You can operate it point-to-point by simply running two clients on two machines and pointing one at the other's IP address. Or, if you want an easy to remember URL, you can sign up for a free account at places like fwd.pulver.net. You'll then be accessible as sip:username@fwd.pulver.net.

Google for "SIP softphones" and you'll find quit a few clients. The big ones on linux are kphone and linphone. Shtoom is making some headway also, and runs on linux, windows, and os x.

Skype decided they don't like either H.323 or SIP, went off and designed their own proprietary protocol, and is keeping it secret from everyone else.

*Ugh* First an obligitory link to Godwin's law because you brought up the Hitler.

That being done, I simply meant that MythTV is one of the Linux applications that is easy to use, fully funtional, and has a professional look and feel. This would be one of the last projects I would like to see die under the weight of litigation. There are few linux applications that I can install on an x-box, put it in front of my mother, sister and brother, and hand them a remote and they can figure it out. It simply delivers. Now I understand all about "fighting the good fight," but I would like to see MythTV continue to grow. If lerhaupt wanted to pick a fight with the MPAA, he could have done it without causing collateral damage to a project I, and my family, love. And I would stand next to him and fight it. Now Isaac will have to spend time distancing himself from this work, which could have never been associated with MythTV in the first place, but still used as a separate application that MythTV could launch (MythTV can launch any app) so the integration/name association was completey unesscessary.

The latest RFC don't deal with broadband over power lines any more. It's been tried, and power companies have folded over this bet.

My own power company gave up and found it more efficient to simply lay TCP/IP fiber along the new power lines instead.

No, the new thing is not TCP/IP over electricity lines, but electricity over TCP/IP lines, as detailed in RFC3251.

The domain, is of course, case insensitive, since DNS is.

" The plans for the Saturn V were already destroyed as part of the space shuttle program"

Wrong. They're at Marshall on microfilm. http://www.faqs.org/faqs/space/controversy/ (scroll down)

can you say that scientologists are total fuckheads in the states then now? because they at least they ARE fuckheads.

You sir have tarnished the good name of our fine cult, I challenge you to a duel aboard an extraterrestrial DC-8. Seriously though, why all the
End Words you insensitive Wog.!

BTW: total fuckheads, you're right.

you can still get to all those sites. You just have to REMEMBER the ip instead of depending on the computer to look it up for you ;). TCP/IP was designed to have not centeral point of failure and still does it's job well. DNS was not quite designed in such a way.

(Score:5, Insightful, right...) Actually, it was. If Google et al were all using a single Akamai backbone TCP/IP routers and they went down, they would be affected as well.

Google was using some DNS servers as their DNS servers (NSs for their domain zone). Their servers went down and then Google was unreachable because their DNS was down, nothing more. Nothing magical about DNS per se. TCP/IP routing was working but this hardly means DNS is any more "centeral point of failure" than TCP/IP. Google should not rely on a single network of DNS servers and it would be fine, because DNS is designed in such a way and has been for over twenty years.

The problem here is the bastardization of DNS standard by Akamai. DNS records should be cached on recursive name servers. Google is used everywhere. If Google had sane TTL and expiration times set for their zone, their zone would be cached by every ISP in the world and their DNS servers could be down for a week and no one would even notice.

This is how DNS should work, can work, and have been working for literally decades. Please read RFC 882: DOMAIN NAMES - CONCEPTS and FACILITIES (P. Mockapetris, November 1983), RFC 883: DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION (P. Mockapetris, November 1983), RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES (P. Mockapetris, November 1987) and RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION (November 1987).

you can still get to all those sites. You just have to REMEMBER the ip instead of depending on the computer to look it up for you ;). TCP/IP was designed to have not centeral point of failure and still does it's job well. DNS was not quite designed in such a way.

(Score:5, Insightful, right...) Actually, it was. If Google et al were all using a single Akamai backbone TCP/IP routers and they went down, they would be affected as well.

Google was using some DNS servers as their DNS servers (NSs for their domain zone). Their servers went down and then Google was unreachable because their DNS was down, nothing more. Nothing magical about DNS per se. TCP/IP routing was working but this hardly means DNS is any more "centeral point of failure" than TCP/IP. Google should not rely on a single network of DNS servers and it would be fine, because DNS is designed in such a way and has been for over twenty years.

The problem here is the bastardization of DNS standard by Akamai. DNS records should be cached on recursive name servers. Google is used everywhere. If Google had sane TTL and expiration times set for their zone, their zone would be cached by every ISP in the world and their DNS servers could be down for a week and no one would even notice.

This is how DNS should work, can work, and have been working for literally decades. Please read RFC 882: DOMAIN NAMES - CONCEPTS and FACILITIES (P. Mockapetris, November 1983), RFC 883: DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION (P. Mockapetris, November 1983), RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES (P. Mockapetris, November 1987) and RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION (November 1987).

you can still get to all those sites. You just have to REMEMBER the ip instead of depending on the computer to look it up for you ;). TCP/IP was designed to have not centeral point of failure and still does it's job well. DNS was not quite designed in such a way.

(Score:5, Insightful, right...) Actually, it was. If Google et al were all using a single Akamai backbone TCP/IP routers and they went down, they would be affected as well.

Google was using some DNS servers as their DNS servers (NSs for their domain zone). Their servers went down and then Google was unreachable because their DNS was down, nothing more. Nothing magical about DNS per se. TCP/IP routing was working but this hardly means DNS is any more "centeral point of failure" than TCP/IP. Google should not rely on a single network of DNS servers and it would be fine, because DNS is designed in such a way and has been for over twenty years.

The problem here is the bastardization of DNS standard by Akamai. DNS records should be cached on recursive name servers. Google is used everywhere. If Google had sane TTL and expiration times set for their zone, their zone would be cached by every ISP in the world and their DNS servers could be down for a week and no one would even notice.

This is how DNS should work, can work, and have been working for literally decades. Please read RFC 882: DOMAIN NAMES - CONCEPTS and FACILITIES (P. Mockapetris, November 1983), RFC 883: DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION (P. Mockapetris, November 1983), RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES (P. Mockapetris, November 1987) and RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION (November 1987).

you can still get to all those sites. You just have to REMEMBER the ip instead of depending on the computer to look it up for you ;). TCP/IP was designed to have not centeral point of failure and still does it's job well. DNS was not quite designed in such a way.

(Score:5, Insightful, right...) Actually, it was. If Google et al were all using a single Akamai backbone TCP/IP routers and they went down, they would be affected as well.

Google was using some DNS servers as their DNS servers (NSs for their domain zone). Their servers went down and then Google was unreachable because their DNS was down, nothing more. Nothing magical about DNS per se. TCP/IP routing was working but this hardly means DNS is any more "centeral point of failure" than TCP/IP. Google should not rely on a single network of DNS servers and it would be fine, because DNS is designed in such a way and has been for over twenty years.

The problem here is the bastardization of DNS standard by Akamai. DNS records should be cached on recursive name servers. Google is used everywhere. If Google had sane TTL and expiration times set for their zone, their zone would be cached by every ISP in the world and their DNS servers could be down for a week and no one would even notice.

This is how DNS should work, can work, and have been working for literally decades. Please read RFC 882: DOMAIN NAMES - CONCEPTS and FACILITIES (P. Mockapetris, November 1983), RFC 883: DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION (P. Mockapetris, November 1983), RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES (P. Mockapetris, November 1987) and RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION (November 1987).

Forth? No.

Learning forth will help you learn reverse polish notation, one specific trick for building high-performance interpreted languages and a very lightweight, easily extensible and embeddable scripting language.

It won't, though, teach you anything about computers work beyond the small amount you'll pick up by learning any new language. Including French.

If you want to learn how computers work there are far better things to play with. Assembly language, obviously, whether it be a synthetic assembly language such as DLX or a real architecture. x86 isn't the most enlightening assembly language to start with (6502 is excellent, MIPS or for a really nice architecture, Alpha) but it'll run on your PC.

Books. Patterson and Hennesey, Computer Organization and Design, The Hardware/Software Interface is pretty good for a programmers intro, but Hennesey and Patterson, Computer Architecture, A Quantative Approach will teach you a lot more, as will most texts with Superscalar in the title

Learn a hardware description language. Verilog is better, but VHDL is OK. Compilers and simulators are freely available for both.

Get an FPGA development kit. Compile yourself some hardware. You can put full CPUs on a fairly cheap FPGA development board.

Design your own CPU. It's possible for an individual or a small group to design a CPU and have it fabricated as a tinychip. I've seen individuals design a full, if tiny, CPU at mask level in a couple of months, and a small group put together a fairly decent gate level design in a few more. Commonly done as part of a college course, but an individual can have a tinychip fabricated for around $1000. Not cheap, but cheaper than some hobbies.

You can do full circuit level design and simulate it using either gate level or spice transistor level simulators and see just why addition or multiplication takes as long as it does.

As a general rule I've found that some of the best software engineers have some hardware design background, and a good understanding of computer architecture, so even if you never plan to do any hardware design, understanding how it all works is a good idea.

Of course, I've also found that a large fraction of good software engineers have also spent time working as theatre technicians, so who knows what the correlations are...

I am not sure from whence your thoughts arose
that RFCs would really exclude these
Since RFCs can e'en apply to prose
and truly be to anything with ease.
That XML does not have one its own
shows limitations not with this process
Rather with those who thought to bring it forth
Without an RFC, XML's a mess.
And so to prove that RFCs stand tall
Do you think this counts as a protocol?

I've heard of IP over Avian Carriers and Pigeon Rank, but outsourcing call centers to ducks is new to me.

Unlike Windows which began as a game-playing, home-using OS and has been modified into something it was never designed to be.

I think Unix started as a game playing, single user OS.

When Bell Labs withdrew from the Multics research consortium, Ken Thompson was left with some Multics-inspired ideas about how to build a file system. He was also left without a machine on which to play a game he had written called Space Travel, a science-fiction simulation that involved navigating a rocket through the solar system. Unix began its life on a scavenged PDP-7 minicomputer, as a platform for the Space Travel game

Bug in your Linux kernel.

It's not properly implementing RFC 1700. 0.0.0.0/32 is valid only as a source address, never as a destination address.

(a) {0, 0}
This host on this network. Can only be used as a source address (see note later).

2. Global and Other Specialized Address Blocks

0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network. Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network [RFC1700, page 4].

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

enjoy

Why not just have SP2 install and patch the system then report in ANY WAY POSSIBLE that this is a pirated copy of Window XP. Try and send information to MS identifying the end user if possible through the IP Address, login name, Dial-Up Networking IP account, address, and provider. Gather information from Microsoft Office as well, any Word or Excel Documents that have addresses in them send those to MS as well.

In other news:

(Reuters) Microsoft's (MSFT) connections to the net gradually ground to a halt following the release of service pack 2 for their popular Windows XP operating system. Analysts are currently conjecturing that this is the effect of an undocumented feature of the service pack whereas if the service pack is applied to a pirated version of the OS, it reports itself to Microsoft in as many ways as possible in order to eneable Microsoft security to track down and positively locate the pirate.

Microsoft spokesperson Heather McGillivray stated in a press conference at company headquarters earlier Thursday that the company has put it's top analysts on the problem. People who are seeking to contact Microsoft in the meanwhile are advised to try alternate methods such as by telephone, telegraph or carrier pigeons. For the later, Microsoft has hastily implemented RFC 1149 and RFC 2549 gateways to it's corporate network.

Why not just have SP2 install and patch the system then report in ANY WAY POSSIBLE that this is a pirated copy of Window XP. Try and send information to MS identifying the end user if possible through the IP Address, login name, Dial-Up Networking IP account, address, and provider. Gather information from Microsoft Office as well, any Word or Excel Documents that have addresses in them send those to MS as well.

In other news:

(Reuters) Microsoft's (MSFT) connections to the net gradually ground to a halt following the release of service pack 2 for their popular Windows XP operating system. Analysts are currently conjecturing that this is the effect of an undocumented feature of the service pack whereas if the service pack is applied to a pirated version of the OS, it reports itself to Microsoft in as many ways as possible in order to eneable Microsoft security to track down and positively locate the pirate.

Microsoft spokesperson Heather McGillivray stated in a press conference at company headquarters earlier Thursday that the company has put it's top analysts on the problem. People who are seeking to contact Microsoft in the meanwhile are advised to try alternate methods such as by telephone, telegraph or carrier pigeons. For the later, Microsoft has hastily implemented RFC 1149 and RFC 2549 gateways to it's corporate network.

<a href="http://www.faqs.org/docs/Linux-HOWTO/Astrono my-HOWTO.html">starting point</a>
<a href="http://www.randomfactory.com/lfa.html">so me software</a>
<a href="http://www.randomfactory.com/lfa/v789info.ht ml">some more software</a>
<a href="http://heasarc.gsfc.nasa.gov/docs/software/l heasoft/">Heasoft</a>

starting point
some software
some more software
Heasoft

Now that's a REAL man - he'd read all the man pages, even wrote some of them himself... In re!

10.3 broke PPTP which I need to connect to my ISP (via cable), now they added an option to disable encryption (apparently MPPE) and that fixed it.
For connecting in 10.3.3 I had to use a shell script but now it works from the GUI too.

Once my exams are over, I plan to look through the KDE ioslaves (at least the common ones in kdebase, kdenetwork etc.) and check what standards they comply with, and whether they appear to be exploitable. I'm not a security expert, but hey, many eyes, right?

That's very kind of you. I'm sure that many KDE users, whether they know it or not, will be very much happier not having their system being attacked.

- Auto-registering protocols from all mounted images, while having URLs that mount a disk image with no user interaction.

Apple need to decide where to put the security barrier - either mounting a .dmg is an expression of trust by the user, in which case Apple should never do it automatically (or at least have an unavoidable prompt before mounting remote .dmg files), or it's not, in which case newly mounted .dmg files should be considered to be untrusted and shouldn't be able to autorun anything. (Or both, of course.)

Right.

- Some protocol handlers are mis-implemented, like the telnet one which accepts telnet:-nfoo (or telnet://-nfoo?) as a request to telnet to the host -nfoo, but naively invokes telnet with the argument -nfoo (which doesn't do what you want).

If Mac OS X telnet used GNU-style arguments, invoking telnet -- -nfoo would be sufficient to get the desired behaviour, but since it presumably doesn't, the telnet: protocol handler should be responsible for filtering out harmful hostnames.

(I observe that a non-GNUish telnet will be unable to connect to certain hosts via command-line arguments: if you actually have a host called -nfoo, it appears that at least Debian's Netkit telnet can only connect by running with no host parameter and instead using the command "open -nfoo")

This (supporting hostnames of the form "-nfoo") is not required. I quote from RFC 952:

The first character must be an alpha character.

Just go outside, and run. Just go. Don't develop a schedule, don't come up with a "plan." Just get it done. Run as far as you can, then walk, then run some more!

Excellent advice - but for those wanting a slight bit more guidance, consider the rec.running beginners FAQ. It can give you a better idea how much to do at first, how to ramp it up, and what to expect. Overdoing it too quickly will send most people back to the couch with soreness and ultimately discourage them.

But I definitely agree, just get up and do it, get into the habit and it'll pay off.

One last recommendation: If you can afford it, invest in a treadmill.

And, a caveat; try running on a treadmill a few times before you spend money on one. There seems to be an even split between runners who swear by treadmills and runners who swear at treadmills. The lack of movement, airflow, and scenery can make them a bit boring; I'd rather run in a snowstorm than run on a treadmill.

Not right now. SRTP (secure realtime transport protocol) is the protocol you're looking for. Very few clients are capable of using it.

If you think that the people behind e164.org are in it for the good cause, you're kidding yourself. There already is an official phone number to DNS tree: e164.arpa, as designated in RFC 2916. This is a fight for the root of _the_ registry of all POTS-number to VOIP/email/web mappings. There's money to be made, and lots of it.

Loadable modules? A module is only loadable when the module build exactly matches the kernel build. The only thing they accomplish is code memory savings.

No, Windows(NT) isn't a 'true' microkernel; it's more like a layered client/server model. However, NT has much better shared (DLL) library support; you can use drivers from NT 3.1 in WS2k3 (NT 5.2). You can use the same binary WDM driver on both Win98 (v4.1) and Win2k+(NT 5.0), two very different OSs.
Many basic parts of NT are loadable modules, things that cannot be .ko in Linux, like the Hardware Abstraction Layer (hal.dll), or the entire system call interface (ntdll.dll). Let's see you use a binary kernel module from the earliest Linux version that supported loadable modules (2.0?) in a 2.6 kernel.

Since Linux was designed to have its source files available, this isn't much of a problem. Windows has to have lots of binary compatibilty, just becuase it is designed to be closed.

Here is a good statement of what Linux kernel modules were designed to do.

P.S. I know you can get my domain from looking at my profile, but I figured I keep the example simple by using [mydomain.com].

Get with the program - RFC 2606 clearly says that example.com has been set aside specifically for this purpose. ;o)

.xxx is once again one of the new TLDs being considered by ICANN, but everybody with a brain knows it won't work. Among other things, you'll never get a world-wide definition of "XXX content", let alone a world-wide law for keeping XXX content in a .xxx TLD. (The nations of the world still can't agree on the what's a "good war" and what's a "bad war"; there's no way they'll agree on the difference between "good nudity" and "bad nudity".)

In fact, the TimBL paper we're supposed to be talking about includes a link to one explanation of why .xxx won't work as advertised. There's also RFC 3675.

If you look at the recently closed public comment period on .xxx, you'll notice a frightening progression: .xxx supporters say ".xxx will protect children." Saner people point out how it won't. Lusers respond with increasinly draconian suggestions for regulating the Internet, like blocking all connections between the United States and countries that don't abide by U.S. laws about adult content.

Support for .xxx is support for Internet censorship. Please don't encourage those people.

You should read this.

RFC 3675 - .sex Considered Dangerous

The Art of Unix Programming

It really is an amazing book. Sure it has a slight anti-C++ bias, but it still covers a great deal of topics with depth.

Sunny Dubey

I don't care if the spammer is American, Chinese or Martian. Well, considering that the Martian addresses are non-routable, I'd say you won't be receiving much spam from there.

For those who don't know, http://www.faqs.org/rfcs/rfc1149.html describes IP via avian carrier. If you haven't read it yet, you should. It pushes the capability of IP under difficult conditions, especially conditions where little to no power is available.

Jesus Christ.

Preview Your posts dumbass (is that too gratuitus)

corrected link.

People do play a game that lasts 2 to six months though. I t is an RTS none the less.

Games usually have between 4 and 100 people so it definatly has people playing it.

The "Fast" game is 24 hours, real time, with action to be taken every ten minutes to keep up.

I never played, I think I am too young to really appreiciate a telnet game (later era DOS games are about as old school as I can handle).

It may be that other considerations you mention result in you still choosing the partially-ethanol 89, but you should realize that you do so at a price.

personally don't mind extra scrutiny if it's in the name of keeping me and my family alive.

People in 1933 Germany were quite happy to put up with Hitler's new policies, and give up "some" of their civil rights, for a variety of perfectly valid reasons too...

With a single sentence you have exemplified both Godwin's law and Arthur Schopenhauer's thirty-second strategem. Readers can draw their own conlcusions about this conjunction of well-documented forms of noxious and invalid rhetoric with "+5 insighful" moderation.

Government survilenace can be used either to protect the safety of law abiding citizens or to deprive those citizens of their privacy and freedom. The former is a shield from violent attack on the innocent, the latter a gurantee of opression. There is hard question: How does a democratic society permit benificial surveilance and disallow oppressive surveilance. Those who condem all government monitoring out of hand (see parent post) are a threat to democracy just as are those who support government monitoring without question; both groups advocate policies which place citizens at risk.

We should have government controls in place to catch terrorists and we should insure that those controls do not become a tool for oppresion by our own government. Those serious about the defense of life and liberty will consider the complicated issue of how to achieve that. We would do well to ignore the extremeists: the tinfoil hat brigade on the left and the "my government can do no wrong" CIA fanboys on the right.

You're both wrong, it makes the most sense to say 2004, May 9.

Take a look at RFC 3339

Like X, Flash can be extremely suckass, but it doesn't have to be. In both cases, this comes from separating policy from mechanism. Since Flash unlike HTML gives you a completely free-form palette on which to paint, it's easy to make it do things that would be more appropriate in a structured medium. And also the opportunity to do useless, self-indulgent intros. To choose a random example: here.

But there are times when Flash is good: when you are dealing with data that does not easily lend itself to html-ish structure (e.g. animated graphics) and when you need to preserve state in a more complex way than forward-back: e.g. Flash games.

That's a trivial example, I know. But recently, my company had to develop a kiosk system for a client: shininess was at a premium, and the underlying dataset (maps of the facility) lent itself to a highly visual interface.

If used in its proper place, Flash is just fine.

Or the raid that the Japanese learned from.

The Japanese military attache in Rome took a long hard looked at what even biplanes could do.

First of all, this web page provides some illuminating information on the exploits that exist in the Mac world.

That's some good info, but it's not an exhaustive list and it kind of proves my point. Now maybe you're definition of "damage" is more literal, but to me, a machine that frequently crashes or has corrupted files is "damaged", at least when we're talking viruses. Now I will agree that there are no known Mac viruses that will do damage to the hardware, but neither are there in the PC world (other than ones that damage the BIOS, which I've read about, but I've never heard of anyone having their BIOS wiped). There really isn't anything out there that formatting the drive and reinstalling the OS won't fix.

Secondly, your questioning of my credentials is predictable. You mention the IIfx. My bug report--submitted in about mid-development--resulted in the SCSI terminators being modified after the machine was released. That was a MUCH bigger problem than any virus you could mention. Your dramatic depiction of the effeects of a corrupt font is touching, but it's still a problem today and isn't necessarily caused by viruses. Not a red herring, but definitely pink.

It was late, if I questioned your credentials, I apologize. However, I believe I was simply stating that you weren't "in the trenches" as it were, and obviously by your comments you didn't see the problems I did. I imagine that the types of users I dealt with (heavy removable media users, and most machines had multiple users) had a lot to do with the number of infections I had to deal with, the truth of which you seem to doubt. When I said 'if you knew what _your_ stuff', it wasn't meant to question your credentials as much as it was meant to echo what you said to me, and to illustrate that a statement like that is easily dismissed. BTW- thank you for that bug report, I vaugely remember something about that problem, although I tended to deal with more SE's, IIcx's and IIci's- in any event I'm sure it made my life easier in some way.

But that statement also illustrates my point, which I should expand upon. I feel your experiences and environment at the time preclude you from judging the validity of my statements. Obviously you were doing "bigger picture" work and I'm sure it had a much broader impact than mine - I didn't mean to imply otherwise, and I'm sorry if you feel I've turned this into a "who's is bigger" debate.

You're right about my working in a "sanitized, utopian environment." That's because we were so aggressive about fighting infections precisely because of their mode of transmission. One bad floppy could infect millions of users if it was included in a build. One careless hard drive transfer could ruin a product release. Believe me, you didn't want the infection traced back to something you did.

Good golly yes - again, I wasn't trying to attack you personally, only your authority to make statements like there weren't any viruses that did any damage or that I was "wasting my time" running Disinfectant. I'm glad you worked in such an environment, and wish that I had at the time been qualified enough and had the opportunity to work in such an environment.

But I stand behind what I said. Go over Apple's product lines between late-1987 and December 2001. It'd be easier to list what I didn't work on than what I did. Your post is interesting but it doesn't represent the typical Mac experience. Period.

Not to question your qualifications, but again I have to strongly disagree (You might want to cover your ears and go "LA LA LA LA LA LA LA" really loudly at this point). Does 1995 ring a bell? PowerBook 190's and 5300's? LC/Performa 5200 and 5300's? While their were earlier problems, I think 1995 was the beginning of some of the worst hardware problems for Apple, and unfortunately, 1995 was around the time I began working with k-12 schools almost exclusively, and they all got a ton of these mo

more information is available in RFC 3580 on the same topic.

First of all, this web page provides some illuminating information on the exploits that exist in the Mac world.

Secondly, your questioning of my credentials is predictable. You mention the IIfx. My bug report--submitted in about mid-development--resulted in the SCSI terminators being modified after the machine was released. That was a MUCH bigger problem than any virus you could mention. Your dramatic depiction of the effeects of a corrupt font is touching, but it's still a problem today and isn't necessarily caused by viruses. Not a red herring, but definitely pink.

You're right about my working in a "sanitized, utopian environment." That's because we were so aggressive about fighting infections precisely because of their mode of transmission. One bad floppy could infect millions of users if it was included in a build. One careless hard drive transfer could ruin a product release. Believe me, you didn't want the infection traced back to something you did.

But I stand behind what I said. Go over Apple's product lines between late-1987 and December 2001. It'd be easier to list what I didn't work on than what I did. Your post is interesting but it doesn't represent the typical Mac experience. Period.