Slashdot Mirror

If there was a priority header like that it would not be long before every packet was a "911" priority. The evil bit is a good example of why this won't work.

The windows disk administrator/manager writes a volume id to the boot/partition section of the partition. This is on both NTFS and Fat systems. This Volume id is 4 bytes and contains coded information to suggest a drive letter if it is availible and marked to do so.

Volume serial numbers don't contain any information. They are completely random based on the time. Although, admittedly, you could be talking about something besides the volume serial number, which is actually eight bytes, when you say 'volume ID', but I don't see anything else in the partition boot area you could be talking about.

With a logical Drive, The drive letter is stored in metedata near the end of the NTFS loader code. This system suggests the drive letter asignment to the IO manage which uses the mount manager when the partition information is read. If the drive letter is availible, It is then asigned to that volume.

I don't know what you mean, 'with a logical drive'. I think You're talking about the $Mft, which does indeed have something called $Volume, but that has the partition name and version, not a drive letter. Feel free to read what Microsoft says about it, and feel free to search for 'drive letter' in that document. (It is there, but not in reference to any information in the NTFS or partition.)

And just in case you were trying to assert it was the partition table the held the drive letters instead of the file system, look here and tell me in which of the 16 bytes that this data is stored. Partition tables are very very cramped.

This volume id is also mapped to a registry area HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices wich coresponds to HKEY_LOCAL_MACHINE\SYSTEM\DISK which solidifies the drive letter asignment if availible.

Well, duh. That's how partitions get drive letters. The operating system hands them out. DOS handed them out inflexibly, NT lets you move them around. They aren't stored anywhere on the partition or the drive the partition is on, which is rather my point, and hence they can NEVER transfer between XP installs.(1)

But, duh, that's so incredibly easy to test I don't know why we're even discussing this, and I know for a fact it doesn't work how you say, because I had a jump drive that was assigned to drive O or something on my computer, and took the first available one on every other one.

Seriously, Windows has a very ordered way for naming drive letters. It only gets complicated a little by what partition formats the OS version can see as well as any preformed lettering criteria. The first drive letter gets asigned to the first primary partition unless another partition on the first drive is marked active. the rest get asigned to the rest of the primary partition in the order the drivers for the device (NT ) is loaded. Then all logical and extended partitions get lettered and then finaly everything else in order of thier bus gets a letter.

I didn't say it assigned them randomly. I said they were assigned as, and I quote, 'picking the first one as the drives are enumerated in their fairly random order'. The order you just listed? First active partitions on the drive, then inactive primary ones, and then move on to the next drive and repeat? When finished, go back and do the logical ones? Then do all non-hard drives? Yup, that appears to be a fairly random order to me.

1) I did say 'machines' there, but actually if you move a disk with an XP install on it, duh, all the drive letter mappings move with it.

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

I mean, come'n if they would be able to audit all e-mail traffic and tax appropriately, this should be a breeze...

Hmmm, no. JPEG is lossy. It's funny how your tone would indicate that you know what you're talking about and in fact you don't. Sad but unfortunately typical.

Right back at ya. There's some info on it in the JPEG FAQ.

One thing which immediately struck me was that the author seems unaware of a key software engineering principle: Reducing design complexity reduces the number and severity of bugs. By now, we all know that there are tradeoffs between complexity, time, and features. However, all other things being equal, some people and organizations consistently produce better software than others. Consider, for example, Linux and Windows. The key reason Linux is more stable and more reliable than Windows is that the process which produced Linux is inherently better at catching and correcting flaws than the one used to produce Windows. Anyone who has ever had to commit a patch to the kernel team knows that design changes are thoroughly vetted before being accepted into the source tree.

Even I have completed some rather large projects without a producing a single bug. It wasn't a matter of coding skill, but rather, that I designed the software such that:

• It was broken into modules with clean interfaces, so that each module could be independently tested and verified.
• It was designed such that a bug in implementation would be apparent immediately (i.e. - it would crash).
• It was designed to accommodate the inevitable change in requirements.

Even very complex software can be written virtually bug free if good software engineering principles are followed. Something as simple as adhering to the Unix design principles can drastically reduce the number of bugs in a shipping application.

Generally speaking, the old adage about "failing to plan is planning to fail" holds true with software as well. The core idea behind software engineering is that quality is improved not by doing more testing, but rather by improving the process by which software is written. Consider the following two, widely used approaches to software:

1. Define the requirements.
2. Design the software as a large, monolithic application with numerous interdependencies and no clean interfaces.
3. (RE)Write the software.
4. Test for bugs.
5. If bug found, goto step 3.
6. Marketing promises something engineering can't deliver. Requirements change; goto step 1.
7. Customer complains that feature X isn't implemented. Requirements change; goto step 1.
8. Marketing adds features to product brochure. Requirements change; goto step 1.

1. Define the requirements.
2. Partition the requirements into easily tested modules separated by clean interfaces, anticipating the need to add future functionality at a later time.
3. Design each module.
4. Write the module(s).
5. Test the module. Bug found? goto step 4.
6. Marketing promises something engineering can't deliver. Requirements change; goto step 3.
7. Customer complains that feature X isn't implemented. Requirements change; goto step 3.
8. Marketing adds features to product brochure. Requirements change; goto step 3.

With the second model, changing requirements do not require a complete rewrite or complicated analysis of the entire system. It is a flexible model. The key problems is that it is a hard sell - the design requirements phase takes more time, but it ultimately provides the flexibility that management and marketing require.

One of these models addresses the fact that requirements frequently change; the other does not. One of these models takes into account the fact that complexity is hard for a single person to manage, and one does not. One model limits the amount of damage that a single, bad coder can inflict, and one does not.

Yes, we may not fix every bug, but we can at least use sound design processes to minimize the impact of bugs. BTW, the fact that Source Gear can't interoperate with other databases is not merely a bug, but a design flaw. Had it been properly designed, using a

No, the original JPEG standard did support Lossless compression. It just wasn't very good and not widely supported: http://www.faqs.org/faqs/jpeg-faq/part1/section-13 .html

Alternately, you can send IP Over wind by way of avian carriers. Just be sure to run a virus scanner on your incoming packets to ensure they don't get the bird flu.

I also heard that something called TPC or TCP is widely used by hax0rs to pwn remote servers.

They don't need a law to protect TCP. It already has RFC 3514. All they need is a similar flag for perl. I think they can just overload the "-t" flag. Perl must be tainted if it is being used for criminal purposes.

I think that the network, with all its erratic latency, is not really the best source to use as a timing transport.

NTP does not just send a packet saying "Hey, here's the time." It compensates for this. You're thinking of the daytime protocol -- early 1980s tech.

NTP v3 (early 90s) is much more sophisticated.

I think that the network, with all its erratic latency, is not really the best source to use as a timing transport.

NTP does not just send a packet saying "Hey, here's the time." It compensates for this. You're thinking of the daytime protocol -- early 1980s tech.

NTP v3 (early 90s) is much more sophisticated.

In 2003, there is a deep ambivalence in our attitude -- a tension between elitism and missionary populism. We want to reach and convert the 92% of the world for whom computing means games and multimedia and glossy GUI interfaces and (at their most technical) light email and word processing and spreadsheets. We are spending major effort on projects like GNOME and KDE designed to give Unix a pretty face. But we are still elitists at heart, deeply reluctant and in many cases unable to identify with or listen to the needs of the Aunt Tillies of the world.

To non-technical end users, the software we build tends to be either bewildering and incomprehensible, or clumsy and condescending, or both at the same time. Even when we try to do the user-friendliness thing as earnestly as possible, we're woefully inconsistent at it. Many of the attitudes and reflexes we've inherited from old-school Unix are just wrong for the job. Even when we want to listen to and help Aunt Tillie, we don't know how -- we project our categories and our concerns onto her and give her 'solutions' that she finds as daunting as her problems.

Our greatest challenge as a culture is whether we can outgrow the assumptions that have served us so well -- whether we can acknowledge, not merely intellectually but in the sinew of daily practice, that the Macintosh people have a point. Their point is made in more general, less Mac-specific way in The Inmates Are Running the Asylum [Cooper], an insightful and argumentative book about what its author calls interaction design that (despite occasional crotchets) contains a good deal of hard truth that every Unix programmer ought to know.

We can turn aside from this; we can remain a priesthood appealing to a select minority of the best and brightest, a geek meritocracy focused on our historical role as the keepers of the software infrastructure and the networks. But if we do this, we will very likely go into decline and eventually lose the dynamism that has sustained us through decades. Someone else will serve the people; someone else will put themselves where the power and the money are, and own the future of 92% of all software. The odds are, whether that someone else is Microsoft or not, that they will do it using practices and software we don't much like.

Or we can truly accept the challenge. The open-source movement is trying hard to do so. But the kind of sustained work and intelligence we have brought to other problems in the past will not alone suffice. Our attitudes must change in a fundamental and difficult way.

Is it that hard to comprehend that someone might not be a Democrat or a Rebublican or part of any political party? I choose and form my OWN opinions about individual issues and how our $current_leaders are performing myself. No group think required, requested, or needed.

Personally, I've said before and I'll say it again, I don't entirely trust any politician Democrat, Republican, or other. A BIG part of my 'problem' with the Republican party is that I was a registered Republican, and I found myself consistently 'at odds' with both the legislation they pushed and the disingenuous way they seem to govern. They do nothing about rising trade deficits, sky rocking federal deficits, plummeting world opinion. Voter apathy favors corrupt well-funded incumbents, and single issues campaigns both of which the Republicans have specialized in for a number of years.

• Failure to obey the Stratum structure of the NTP system
• Failure to follow the permisions structure of the NTP system
• Failure to properly impliment the NTP connection protocol
  

Everybody talks about BSDs as being fabulous firewalls, which I don't deny, but what can they do that linux + iptables & tc can't?

Here's a similar rate-limiting deal: http://www.linux-noob.com/forums/lofiversion/index .php/t1829.html

And Linux has all kinds of QOS capabilities:
http://www.faqs.org/docs/Linux-HOWTO/Adv-Routing-H OWTO.html

This is not a troll, it's an honest question. Why BSD for firewalls?

Wanna talk suicide rates? [of Japan and America]

Sure. But even with 5 in 100,000 more people taking their own lives, the Japanese are living a lot longer than Americans.

Well, I was kinda shooting for a joke there. "Sure it does" is one of those phrases that if you say it seriously is positive, but with a slight change of inflection is extremely negative and sarcastic. Just trying to have a little fun with the original poster, but nobody got the joke. In a way, that's kinda funny too considering the topic.

Anyway, as for the "fired if you don't understand the lunch email"...well, I agree with you in spirit. Kinda. Read the RFC for SMTP, 2821 and you'll understand my objection. Here's the important bit, from 4.5.4.1, "Sending Strategy":

In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information.

The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.

In other words, if the network is busy or some other odd hiccup happens, the RFC recommends waiting a minimum of a half an hour (or possibly a lot more) before a retransmit. This is why time sensitive stuff should never be emailed - you could be fired for not showing up for that lunch, and it may not be your fault at all. I personally have seen email messages sit in a queue for as long as 2 days before my recipient receives it.

You mean like the evil-bit RFC?

But they can't patent this.

RFC 3514 proposed the Evil Bit in 2003.

how the current heirarchical domain system works ... we would have to change quite a bit

The average AOL user is reason to doubt darwin

You're mistaken.

Animal data should be opposed to the usual electrical data (phones, computers).
It is data transmitted using RFC 1149

This seems good, otherwise Google for "ows compression OR compress OR compressor", and according to this, OWS stands for the author's initials.

There are workarounds.

From a previous post of mine:

It's a bad idea.

If you want to rate pages, there are already standard mechanisms for plugging content metadata into pages. Just for a start, this is a technically-superior system -- there is absolutely no reason to need to purchase an entirely separate TLD just because you have a few pages that contain adult content. The domain name registrars would have loved this -- heck, they'd love people to have to buy a new TLD for *every* sort of content, not just adult.

In addition, .xxx is a blanket statement. It allows only one bit of information to be stored regarding a website -- contains "adult" content or not. Use a tagging system, and you can say contains NUDITY, contains PROFANITY, whatever.

So .xxx is already a vastly technically outclassed solution.

What else is wrong with it? The obvious point of such a TLD would be to block .xxx URLs from people. However, TLDs are exceedingly poor technical choices for this purpose. It would be just as easy to obtain this data via the IP address or an alternate URL, not just .xxx. Hell, I could easily see someone setting up a DNS that mirrors .xxx just to screw with the system -- foo.xxx would also be reachable via "foo.xxx.pornbypass.com"

Any proxy usage will bypass a .xxx TLD block, whereas metatags in a page cannot be bypassed (unless the proxy specifically filters these metatags out).

And, finally, the worst issue. It promises a long and unpleasant future of social problems, precisely because it is a TLD. Even if this were a technically good solution, it would still be better to have .xxx.us. There are undoubtedly some people who honestly don't realize that there are vastly different social standards in the world. In a conservative Muslim country, what we consider street clothing on a woman might be considered obscene. While we consider female toplessness unacceptable in the United States, folks in the UK get female toplessness on their TV regularly. No matter what bar is chosen for .xxx, it is going to be completely unacceptable to some people.

The argument "more data is better than none" does have some merit, but the disadvantages of .xxx -- the fact that it is essentially a new tax sending money to registrars, the fact that it will cause social friction between countries, the fact that it starts a precedent of using TLDs to segregate content (completely broken, unless you have only one classification that you wish to do on the Internet), the fact that it ignores metatags...I honestly think that every person out there that is in favor of a .xxx TLD has not thoroughly thought through the implications.

[The reason that the Christian right is opposed to this is for *completely* different reasons. Their concern is that introducing a .xxx TLD will legitimize porn. Europeans have a certain right to be irritated that these concerns are dictating how the global Internet is run -- however, I strongly doubt that they have any impact. The standards folks are already strongly opposed to a .xxx for actual technical reasons, and has released an RFC 3675 on why it would be a really bad idea to implement it. This is what ICANN is going to pay attention to.

There are plenty of technical reasons why not to do it. See RFC 3675 for details.

The only justification for new TLDs that I've seen is that it makes companies have to buy them to protect their trademark, thereby making profit for the new registrar.

It has also accused the commission of collaborating with its rivals in the software industry

From all I heard, even IBM after it's first anti-trust case was less verbal. After second one IBM have learned the lessons and changed completely the way they do business and cooperate with others in industry.

IMHO, M$ must be fined for just going around and telling press that they did nothing bad. After they were found guilty. Twice - not less - in US and EU. It's just hard to beleive M$' top management flies so high in the skies...

P.S. I wonder what kind of disaster would happen when they fall. It's just like RFC 1925, rule #3.

Some other standards efforts they have participated in include SVG and iCal, which are noteworthy for the exceedingly long time it took to ratify them. And wouldn't you know, in the meantime Microsoft was working on proprietary alternatives!

Pah, try beating my magnets I run over the telephone cable.

Come on, the RFC on this is several years old!

Damn networking hardware monopoly is hampering progress!

You don't need a database for sorting algorithms (think gnu sort), but what this will almost certainly do is complicate backup and transfer of bookmarks. I really can't understand what is wrong with a simple text file. Do they not see all the issues Microsoft has because of their registry format??? This is NOT a speed or sorting issue. (I could care less about the history, but don't think that will help anyone other than some possible edge cases there either.)

This will also almost certainly kill any chance of reusage of bookmark data by other programs - which could be a really inovative area if the barrier to entry is kept low. They need to read the Art of Unix Programming.

http://world.std.com/~reinhold/dicewarefaq.html#su bpoena

and
from http://www.faqs.org/faqs/pgp-faq/part2/

3.21. Can I be forced to reveal my pass phrase in any legal
proceedings?

Gary Edstrom reported the following in earlier versions of this FAQ:

- -----
The following information applies only to citizens of the United
States in U.S. Courts. The laws in other countries may vary. Please
see the disclaimer at the top of part 1.

There have been several threads on Internet concerning the question of
whether or not the fifth amendment right about not being forced to
give testimony against yourself can be applied to the subject of being
forced to reveal your pass phrase. Not wanting to settle for the many
conflicting opinions of armchair lawyers on usenet, I asked for input
from individuals who were more qualified in the area. The results
were somewhat mixed. There apparently has NOT been much case history
to set precedence in this area. So if you find yourself in this
situation, you should be prepared for a long and costly legal fight on
the matter. Do you have the time and money for such a fight? Also
remember that judges have great freedom in the use of "Contempt of
Court". They might choose to lock you up until you decide to reveal
the pass phrase and it could take your lawyer some time to get you
out. (If only you just had a poor memory!)

Suggestion:
-Verify requests
-Verify directory computers have not been comprimised
-Disallow amplified data
-Build a new secure system for handling traffic

Actually, a much better solution is to enact the evil bit. You claim that there is "no identification layer to the 'net", but RFC3514 was exactly for this purpose. Any packets that could be deemed "evil" should be marked as such. Then we just prevent the distribution of evil-bitted packets to children.

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

Running emulators natively on Amiga's onboard hardware absolutely was slower than using an add-on graphics card. Here's the reason, shamelessly stolen from http://www.faqs.org/faqs/amiga/introduction/part1/ :

Simply put, the terms `chunky' and `planar' (short for `bitplanar')
refer to different ways of storing graphics information in a computer's
memory. They are rather easy to understand, as far as things go, but
incredibly difficult to explain:

Computer images are arranged as a grid of pixels, each of which can
be thought of as a number representing the color number of the pixel,
sort of like a paint-by-numbers scheme. For example, here's a
simplified example image, in four colors:

00302132

The Amiga stores this image in a `bitplane' mode. That is, it is
represented by several planes of bits (binary digits, 1s or 0s). This
is a four-color image, so each color number could be represented by two
bits. Therefore there are two bitplanes:

00100110 Here's bitplane 0
00101011 And here's bitplane 1
-------- Now, let's add them up, binary style:
00302132

Which is the final image. If the image was in two dimensions, it
would truly be composed of bit planes. However, I'd need three
dimensions to show multiple bitplanes overlayed, and therefore for
simplicity we're working in one dimension (which is all we need).

Now, there's another way of storing this image. How about if we
localize the bit data in little chunks?

00 00 11 00 01 10 11 01 = 00302132

This is the principle of the `chunky' pixel mode.

Both methods of image storage are perfectly logical, and no one can
say that one is better than the other. However, there are certain
technical aspects which cause certain advantages and disadvantages.

First, if you've seen colored text scroll on your Amiga, you know
there is a bit of "flicker" that arises. Specifically, what happens is
that while the text is scrolling, its color temporarily changes to
something completely different. What's happening is that the computer's
moving several bitplanes of data while the raster (monitor electron
gun) is sweeping across the screen. What that means is that, if the
raster catches the data while it's being moved, you can end up with some
bitplanes being moved and some not. What if we filled bitplane 1 in the
example above with 0s? Instantly all the 3s become 1s, and the 2s
become 0s! This is what causes "flicker" when certain colors are
scrolled. By contrast, if a chunky pixel display is caught while
scrolling, all we see is a partially-scrolled image; the colors are
preserved (since their units are the small ones).

That's a disadvantage to planar pixels, but what about chunky pixels?

I'm a recovering sysadmin. One of the things that got me to quit my last sysadmin job was a friend who said, "The graveyards are full of indispensable people."

BGP is just a way for two adjacent routers to exchange their routing prefixes. It isnt 'part' of IP itself. The two routers must have static/fixed IP connectivity between them already which is itself not dependent on the BGP routes. As far as the actual protocol iself, it runs over TCP. BGP is something that can take a while to wrap your head around, but once you've figured it out it makes perfect (well ok almost perfect) sense.

FMI see http://www.faqs.org/rfcs/rfc1771.html

I still go with the age old adage of "You have to learn how to crawl before you can walk" or maybe it's walk before you run, look before you leap? Whatever....

Anyway, I'd say someone should start small and work their way up to the more modern languages. So my suggestion would be:

1. First learn something like the Apple ][+.

1a. Learn Applesoft and maybe some DOS 3.3 or ProDOS assembly. This will make you thank god someone came up with floating point math processors and disk drives that don't require knowledge of how to time when to read/write something to a disk drive.

2. Then learn something like the Apple //gs, Atari, or Amiga.

2a. So you can learn that color really makes a difference. Here you can learn Pascal, about compilers, and the like.

3. Then try the Macintosh and try out Windows.

3a. And ask yourself why Apple, after going all the way to the //gs with color suddenly decided that black and white was all the rage. You can also learn a lot about structured programming, handles, Pascal, C, FORTRAN, COBOL, and lots of other useful information.

4. Then try Linux and you will go - why didn't everyone go with this to begin with? You can also then learn OOP, C++, Ruby, Python, PHP, and everything else.

If you give six months to each of the above you will be a lot better off knowing why some of the things that are still drawbacks to OSs are still in there. Some are just carry-overs from yesteryear. The important thing though - is that you will at least have a grasp of the "why" certain things happen like they do. (Or maybe at least you'd have a hint as to the why.)

For languages I'd say Applesoft Basic first, then maybe QBasic (which I hear is now free from Microsoft), then FORTRAN (to learn the separation of variables into float, int, etc...), then Pascal (to help with the structuring), then C, then C++, then into Python, Ruby, whatever.

The thing is - if you do not get the basics, then you wind up like the System Programmer I once met. Didn't even know how to make a cursor move on the screen. "Duh....the terminal does that. I can't control what it does." Ever hear of ASCII control codes? "Nope. What are they?" Ever hear of the curses routines? "Nope. What are they?" Yeah. System's Programmer.

Or you get the System Operators who were running the computer at a company I used to work with. They were running a program that slowly but surely gobbled up all of the memory on the system and then the computer would crash. (This was a mainframe system with something like 10GB of memory on it back in the late 1980's! Although at the time I think they referred to it as 10,000MB of memory. Each person on the computer gobbled up 100MB each because of the program they were running and there were 300 people who kept trying to use the program.) I went over, looked at what they were doing and told them to run a program (which was in their manuals) that would recover the memory let go by programs. "We can't do that," they said, "it might crash the system." I looked at them and said "And the alternative is....?" They wouldn't do it and so I just went "Well, it's not my system so crash away!" They did - on a daily basis. Sometimes two or three times a day. Their solution? "WE NEED MORE MEMORY!"

RFC 1925 should be required reading for everyone who thinks they have a bright new idea for a network. In this case the company should pay particular attention to rule number two:

[2] No matter how hard you push and no matter what the priority, you can't increase the speed of light.

Since the signal has to travel a certain physical distance, there will always be unavoidable lag. Changing the NIC will have little to no effect, unless you are using some antiquated card that was designed around the early TCP/IP stacks. And gamers are hardly known for not having hardware that is so cutting edge the wounds are still bleeding.

I'm waiting until some new VC-funded company requests major sums of money to build a NIC that communicates on the basis of quantum enatnglement for zero lag. Not to buy one, you understand, since you can't send information faster than the speed of light -- not even by entanglement.

And have a read of the RFC I mentioned as well. Well worth the time.

Ah that last post is where you just proved you don't know what you are talking about. SSH was designed to be a secure protocol for a man in the middle attack. It does absolutely nothing to secure the server. Its not secure in the way you were using it above.

  To do what you want you use things like having SSH come in via restricted shell into a chrooted environment. Etc... But basically you shouldn't be running a Unix at all if you can avoid it, Unix isn't good with untrusted users who have reasonable access to the system.

Actually, it is 100% possible for you to set up traffic bandwidth shaping so that any particular IP is only allowed a certain amount of bandwidth, for example.

Use a UNIX-like machine as a router/firewall for your network, and you suddenly have amazingly detailed networking possibilities within your reach. I strongly suggest reading the Linux Network Administrator's Guide. Even though it's getting a little outdated it has some downright cool-ass information within.

Of course, few users are technically adept enough to actually set up a router like this, but I'm sure it has been used a lot for people who want to keep their wifi access "open", but safely limited.

On a related note there are pre-built linux firewall packages out there which will surprisingly easily allow you to do what I was just talking about.

Also, here is the Linux Advanced Routing & Traffic Control HOWTO ... It's a bit technical but a useful resource nonetheless.

The first attempt in the IP world to add a protocol of this type was Reliable Data Protocol, in 1984. (See RFC 908). But that never went anywhere. Since then, nobody has really addressed this. There was ISO TP4, but that didn't go anywhere either, althoug it was fully supported in Windows NT.

SCTP has reasonable congestion behavior, like TCP, so it's an improvement over UDP-based protocols in that regard. Moving some UDP-based protocols to SCTP could be a step up. That's where it could be most useful. It might make sense to put remote procedure call type protocols that now use UDP onto SCTP. If a protocol has to do retransmission, it's better to do it at the transport layer than at the application layer.

The "multihoming" thing seems badly placed, because that's not properly a transport layer function. But I haven't really looked at that.

John Nagle

... is to filter for the Evil Bit.

Set the evil bit on such traffic, so that it may be filtered out via firewalls.

The American Red Cross (which keeps other organizations and programs from using "Red Cross" and the emblematic red cross; the BSA was caught in this and when the ARC threatened to sue the BSA over this, the BSA changed their First Aid Merit badge to a GREEN CROSS with a RED background. This is also why the Safety Merit Badge has a WHITE CROSS (instead of "Green Cross for Safety{tm}", which is a registered trademark of the National Safety Council) with a GREEN background)

(http://www.faqs.org/faqs/scouting/rec.scouting.is sues/section-9.html)

There's a little cite. They also talk about some other organizations with federal charters.

...is still valid? Do one thing, do it well.

Imagine that - simple, solid advice survives time. Reminds me of the Twelve Networks Truths of RFC 1925 Section 2-11

Why not use the IMAP4 IDLE command? This is the standard mechanism for making mail appear instantly over IMAP. Microsoft in this case writes both the client and the server, so they should be able to add support if it doesn't already exist.

Maybe there's some reason they want to avoid leaving TCP connections open? Do they have trouble maintaining connections as the devices move around, perhaps? Or is there some scalability limit on their server?

Except... the moon doesn't rotate. Well, it does, but very slowly. I doubt it would give you much of a boost.

I think it's defined in RFC2822, but I'm not sure how it varies in temperature. Links, anyone?

Algorithms CAN be patented, and this is a big problem. For example, see this list of data compression patents:

http://www.faqs.org/faqs/compression-faq/part1/sec tion-7.html

For over a decade, everyone avoided using arithmetic coding for compression (even though under certain circumstances it was better than huffman coding etc) because the arithmetic coding algorithms were all PATENTED.

For example, IBM owns almost 20 patents on arithmetic coding:
4,122,440 4,286,256 4,295,125 4,463,342 4,467,317 4,633,490 4,652,856 4,792,954 4,891,643 4,901,363 4,905,297 4,933,883 4,935,882 5,045,852 5,099,440 5,142,283 5,210,536 5,414,423 5,546,080

A handful of other companies own patents on arithmetic coding too.

See RFC 3514.