Slashdot Mirror

I just finished porting lavaps to Mac OS X, and almost all the system calls I had to make to get the info about running processes were mach system calls. I only used one bsd system call (sysctl), around 6 mach calls I think.

too bad they didn't come up with a better notation. instead of hex 0-F just use 0-9,a-Z and 128bits can be represented in a legible string of characters.

RFC 1924 defines Base-85, a compact encoding scheme for 128-bit IPv6 addresses. An address represented in the usual form would be ' 1080:0:0:0:8:800:200c:417a'. That same address in Base-85 becomes '4)+k&C#VzJ4br>0wv%Yp'. Unfortunately, Base-85 addresses aren't very memorable, and worst of all, they're case-sensitive. Try reading that out over a phone. RFC 1924 was released on an April 1st, so it's probably not serious.

you could even argue the need for a dns system since you wouldn't need any service to associate "google.com" with an ip.. the ip could very well be "google.com"

That would be bad:

• Routing would necessarily have to be based on domains (eg, a packet travels to a router responsible for "com", then one responsible for "google", then one responsible for "www").
• It wouldn't be compatible with the existing DNS. "www.google.com" in such a system may not necessarily have anything to do with the current owners of the google.com domain. Talk about squatting possibilities, and confusion.
• The existing DNS adds indirection. "google.com" and "www.google.com" can have identical IP addresses in the current system, and hence be routed identically. In your system, those would be two separate nodes, which would reduce flexibility.
• And, since addresses would be variable-length, routers would have a hell of a time parsing packets.

As others pointed out, BitTorrent isn't for streaming. Check out YOID or End System Multicast.

After dozens of attempts to get AOL to implement the most rudimentary outgoing filters on their Email system, and getting ZERO response, I have regretfully informed our user base that we will no longer accept any Email emanating from any machine with an AOL.COM IP address.

They are breaking the rules of the Internet (see: SMTP RFCs) by improperly implementing postmaster@aol.com (see rfc-ignorant .orgfor details) and their mail relays have sent hundreds of viruses into my domain.

I have asked all AOL users at my site who wish to continue emailing their home addresses from work to get a new service provider and given them two months to do so. I have recommended several small local ISPs to them that I know provide good service and never allow easily detected virii like Yaha, Klez and SoBig to transit their mail hubs.

We, fellow slashdotters, can use our enormous power as administrators of email hubs to get AOL's attention - since it seems more civilized methods are useless. The social contract of the Internet is simple; play by the rules (i.e. implement the required RFCs) or you are not part of the community.

The committee also heard from Sen. Charles E. Schumer (D-N.Y.), who advocates a nationwide do-not-spam registry similar to a newly created do-not-call telemarketing list, plus an international treaty on spam.

According to RFC 1541 the .int top level domain is for organizations established by international treaties.

IPAC with QoS!! RFC2549!
Cheap, but maybe not that fast...
There also seems to be a reference on slashdot!

The RIAA is doing this out of utter desparation.

I hope you're right, though it is unlikely. They are basically saying 'we are watching you' and this makes many people uncomfortable at least.

Quite obviously the next step for p2p swapping networks would be to add an anonymity. There are many ways to do it - to create virtual network like X-bone does or to convert indivdual nodes to the proxies or something else. And as pipes are getting fatter, an overhead of overlaying custom p2p topologies over Internet will no longer create any performance or scalability issues. The technology is not a rocket sience, it's already here and once end-users are diverted away from existing p2p networks - watch them switch to new ones. That's basics of the evolution :)

From RFC 2549
The highly unofficial CPIP WG
Pigeon-powered Internet takes flight

4. Processing of the Evil Bit

Devices such as firewalls MUST drop all inbound packets that have the
evil bit set. Packets with the evil bit off MUST NOT be dropped.
Dropped packets SHOULD be noted in the appropriate MIB variable.

Also, the name servers get a surprising number of queries FROM RFC1918 addresses (10.x, 192.168.x, etc.), and while it may be more efficient to use root server CPU (on big fast computers) than router CPU to dispose of these queries, ISPs have ENTIRELY no business accepting IP packets FROM these addresses, and they should be killing them at the incoming edges of their networks, not carrying them and passing them on to other people.

currently there is no standard for the medium the transmits your IP packets so it is unlikely for two IP stacks to work over IEEE 1394.

Huh? What about RFC 2734? It's a standards-track protocol for sending IPv4 over IEEE 1394. Apple has a beta implementation for Mac OS X and I believe Microsoft has an implementation for Windows XP.

Also see RFC 3146 (IPv6 over IEEE 1394) and RFC 2855 (DHCP for IEEE 1394).

Why is this news?

Distributed systems that do not rely on a centralised authority, be it for synchronising or resource distribution, are by far not a new thing. To name a random example (and you can find a dozen others with five minutes of Googling), the Prospero Resource Manager was a USC project started in the early 90s that relied on distributed authorities with no centralised command centre.

Furthermore, if the computers are self-controlling and not guarded by anything besides their internal mechanisms that rely on the checks on other computers, the potential danger lies in a computer in the grid having a seriously fscked-up internal state. In other words, can a malfunctioning computer be trusted to monitor itself correctly? I think not.

In general, there's a lot of confusion about Public Key Infrastructures, partly because of the big gap in the middle of "1. Write Marketing Hype!! 2. ???? 3. ???? 6. PROFIT!!" chain, but mainly because there are different ways to answer questions about "Who's certifying whom or what to do what or be who or what?" which lead to different applications and solve (or fail to solve) different business problems. One major effort to address this systematically is the IETF SPKI Simple Public Key Infrastructure group, much of which is based on the work of Carl Ellison and Ron Rivest (RFC2692, Requirements, RFC2693, Theory.) It turns out that, while the "Some Authority Certifies that You have Documents with your True Name" model that's popularly used is often useful, it's often not the right model, and there are often more useful relationships, such as the DNSSEC authentication used for web sites and email.

In general, there's a lot of confusion about Public Key Infrastructures, partly because of the big gap in the middle of "1. Write Marketing Hype!! 2. ???? 3. ???? 6. PROFIT!!" chain, but mainly because there are different ways to answer questions about "Who's certifying whom or what to do what or be who or what?" which lead to different applications and solve (or fail to solve) different business problems. One major effort to address this systematically is the IETF SPKI Simple Public Key Infrastructure group, much of which is based on the work of Carl Ellison and Ron Rivest (RFC2692, Requirements, RFC2693, Theory.) It turns out that, while the "Some Authority Certifies that You have Documents with your True Name" model that's popularly used is often useful, it's often not the right model, and there are often more useful relationships, such as the DNSSEC authentication used for web sites and email.

There are basically two kinds of attacks...prevent the system from working (such as with a DDoS attack), or corrupt the data they serve by inserting replacing or making unauthorized changes. The former is a pretty well understood networking problem for all kinds of protocols, although DNS by its design of being heavily distributed and mirrored has some natural immunity.

However the protection of the data that the TLD (or subdomain) servers hold is perhaps the most important. That data is after all what our beloved TLS/SSL web browsers use to verify the sites that we visit. All TLDs run with the DNSSEC extensions which includes all the crypto stuff which signs and protects the zone data, along with many other standard computer security techniques. There are even minimal requirements that all TLD servers must adhere to RFC2870, which contains some very interesting clues as to what they do. Also the Internet Software Consortium which runs the F root server sometimes provides information about their operations on their site; especially when they were bidding to take over the .org domain a while back. Diversity is the other protection, different TLD servers use different hardware and software as well as being locating in different geopolitical regions.

.gov is for US government institutions

Check out RFC 1591

United States Only Generic Domains:

GOV - This domain was originally intended for any kind of government office or agency. More recently a decision was taken to register only agencies of the US Federal government in this domain. State and local agencies are registered in the country domains (see US Domain, below).

D'oh! Figures - try to be smart, and screw up the link... Here's the correct RFC link (the RFC number 2616 was correct).

15.6 Authentication Credentials and Idle Clients Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further extensions to HTTP. [...]

Zope uses session cookies (as do most sites - mod_session in Apache, for example), meaning they have implemented a clever but common work-around. The browser will send the username/password for every single page after using basic authentication, but since Zope knows the Session ID for the client (stored in a cookie), it will intentionally respond with a "404 - Authentication Required" error when the user clicks on the logout button (meaning the browser thinks the username/password was wrong, thus clearing its local cache of said information). The problem is that the authentication is really based on the cookies, not the "standard, universal" authentication. Zope only uses Basic Authentication to get the initial username/password, and then relies on cookies thereafter.

I'm all for standards, but when they lack in basic funcationality, other methods must unfortunately be utilized.

(ps. I'm no Zope expert, so please correct me if I'm wrong and there's some hidden feature of HTTP I'm not aware of).

I'd rather have something like this where the From: address is guaranteed. Additionally, it doesn't require 100% participation from all mail servers. If yahoo.com decided they wanted to implement this to prevent @yahoo.com addresses from being forged, they would be able to without requiring support from other mail servers. Essentially, anyone would be able to ask an ISP whether the mail actually came from them and from that user.

Unfortunately this is not nearly as far along as STARTTLS. I guess STARTTLS would be better than nothing.

I started work on this, and have an Internet-Draft discussing a possible extension to do this: draft-church-dns-mail-sender-02.txt. Unfortunately, I've been too busy/tired lately to take it any farther, so if anyone wants to use it as a starting point, feel free.

On my linux tablet I use the touchscreen normally as you would a mouse. Works just fine for surfing, playing mp3's, etc.

For many things xstroke suits my needs quite well. (I've had a Palm for years so I'm used to grafiti. When I have to have a keyboard I pull up xvkbd and if I really need to type I plugin in one of those "industructable" keyboards that I keep in my desk or drop into my satchel.

So yeah, linux tablets work well, and having the power to download OSS apps, and or develop my own tools makes them excellent tools for the "power" user.

..next step get kdepim on it to sync with my desktop and my Palm...infomation everywhere, yeah team!

I've been using a tablet PC (Viewsonic Viewpad 1000) for several months with Linux. The touchscreen works fine, there's an on-screen keyboard, and while I haven't bothered to get xstroke (Grafitti-like, full-screen handwriting recognizer) working, there's a Debian package and I have used xstroke a lot on the iPaq -- It Just Works.

My company is planning to use them as portable wireless point-of-sale systems for restaurants. They allow waiters' orders to get back to the kitchen and bar a lot faster, which can speed up table turn times by a couple of minutes. May not sound like much but it's important to restaurant owners.

Bill Gribble
Linux Developers Group

Formed in October 1998, the Internet Corporation for Assigned Names and Numbers (ICANN) is a non-profit, private-sector corporation formed by a broad coalition of the Internet's business, technical, academic, and user communities. ICANN has been recognized by the U.S. and other governments as the global consensus entity to coordinate the technical management of the Internet's domain name system, the allocation of IP address space, the assignment of protocol parameters, and the management of the root server system.

As a technical coordinating body, ICANN's mandate is not to "run the Internet." Rather, it is to oversee the management of only those specific technical managerial and policy development tasks that require central coordination: the assignment of the Internet's unique name and number identifiers.

Now, if only it didn't cost $15000 for the card... :(

I'm glad I'm using 1024bit encryption. They've worked so hard to do 64 bit. But each additional bit is a redoubling in the amount of computing power it's going to take to decrypt my packets. Good luck!

This is a good joke, but misleading to readers that might not know better.

For their sake: SSH uses both public key and private key (or symmetric) cryptography. Public key crypto uses keys with thousands of bits; private key crypto uses keys with hundreds of bits (older algorithms like DES used only 56). RSA, DSA, and so on are examples of public key crypto. RC5, Blowfish, and such are example of private key crypto.

Their key lengths aren't comparable at all. Whether or not RC5 is "secure" at 64 bits has absolutely nothing to do with using 1024 bits in authentication and session key negotiation.

On MacSlash, until Siracusa sees the light shining out of my ass on the evils of HFS+ metadata, he's just one more Mac bigot.

Filename extensions where invented back in command line days. They made a certain amount of sense when you didn't have a lot of different file types, or a robust file system for keeping track of them. Now you have dozens and dozens of file types.

File extensions are just not adequate to record this level of information. Too many have multiple meanings. (My favorite example is .WMZ, which means "Compressed Skin" to a certain media player and "Compressed graphic metafile" to a certain office suite -- both from the same company!) And how are users supposed to deal with them? If you have to specify an extension every time you copy or rename a file, Captain Murphy will make sure you get it wrong at the worst possible time. (Even worse for non-techies, who often don't know/forget that extensions are important, or can't remember all the ones they need to know.) If you leave it up the system, you're at the mercy of applications that play with extension associations without telling you and that impose "descriptions" that are more advertisements than useful classifications.

If there are problems with the way Classic does metadata, that's an implementation issue, not a flaw in the concept. Anyway, is file-type fascism on the Mac any worse that extension stealing on Windows?

If I have an issue with Siracusa about metadata, it's that his arguments on the subject tend to wander into obscure abstractions and complicated psychophilosophical rants. Computer science has some arcane roots, but computer people are a pragmatic bunch -- you can only convince them with specifics.

I have to comment on your use of the word "bigot". My American Heritage Dictionary defines "bigot" as "One who is strongly partial to one's own group, religion, race, or politics and is intolerant of those who differ." Dismissing other people's opinions by with simplistic stereotypes and scatological insults would seem to fit that definition.

Of these generic domains, five are international in nature, and two are restricted to use by entities in the United States.

World Wide Generic Domains:

COM - This domain is intended for commercial entities, that is companies. This domain has grown very large and there is concern about the administrative load and system performance if the current growth pattern is continued. Consideration is being taken to subdivide the COM domain and only allow future commercial registrations in the subdomains.

Seems there is an extension to DHCP to provide a URL: rfc2485 (thanks Matt). The actual authentication in that case is by UAP. (Now we just need some client support)...

I'd like to see their implementation of RFC1149!

SIP is an open protocol, so what is special about this?

Provision of names in .za isn't a service such as education or healthcare that a country provides to its citizens; it's merely one part of the vast decentralised database called the DNS. There's nothing "obvious" in saying that any one part of the DNS should be controlled by anyone in particular, other than that it should be controlled by someone competent to do the job (and, by all accounts, the ability to run nameservers competently is not universally believed to be a property of the South African government).

It's difficult to better the way Jon Postel put it in the relevant standards document, RFC 1591 ("Domain Name System Structure and Delegation"), sec 3.2: "These designated authorities are trustees for the delegated domain, and have a duty to serve the community. The designated manager is the trustee of the top-level domain for both the nation, in the case of a country code, and the global Internet community. Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community." (emphasis mine).

[register.com] told me 'Somehow your zone file got corrupted, you have to realize that .us domains are a new thing and it's not going smoothly for many people.'

Maybe what the should have said is "a new thing for us". I remember several years ago registering a .us back when it was run by someone competent. Once VeriSign/NSI took it over, I knew there'd be problems. I moved across the country after this took place, tried to register a new .us domain using the same application I'd used, substituting for the new state and locality, and was rejected because they couldn't read plain English. They suggested some assinine, misspelled name which was only tangentially related to what I'd requested, even though the domain I was requesting was available.

I can't imagine that things have gotten any better since then, even with a new company handling .us registrations. Since I was rejected, I've gone with a .org domain through joker, and haven't looked back since.

In their attempt to monopolize as much domain registration as possible, VeriSign/NSI has managed to cause a lot more damage for .us than there have been benefits.

telnet sitename 80

There's an awful lot of overhead in that one for a protocol you're not even using when you connect it to an HTTP server! Here's a lighter-weight alternative:

nc sitename 80

(What's nc?)

Because if you have 520 ms latency which is the standard for SAT you cannot get more than this speed. TCP window cannot grow more. It is inherent feature of the protocol.

Ah, grasshopper, satellite services may tweak TCP protocol to achieve better throughput, see RFC 1106, RFC 2488, RFC 2760, and there are also proprietary solutions as well.

ftp://ftp.isi.edu/in-notes/rfc3271.txt

ftp://ftp.isi.edu/in-notes/rfc3271.txt

>>Face it, processors are faster than telecommunications.

>The architects of IPv6 disagree. They did away with fragmentation inside routers and made the header size constant to shave a few milliseconds off every packet. With the advent of Tbps optical links and optical routing, processors are about to bite the dust.

>>Face it, processors are faster than telecommunications.

>The architects of IPv6 disagree. They did away with fragmentation inside routers and made the header size constant to shave a few milliseconds off every packet. With the advent of Tbps optical links and optical routing, processors are about to bite the dust.

NIS works great - I would highly recommend it. I agree with the parent poster in that using NIS is the obvious thing to do - the most simplistic google search would reveal that.

http://www.linuxfocus.org/English/July2001/article 148.shtml is a good NIS howto.
http://www.isi.edu/~govindan/cs558/nis/ is a good basic overview.

NIS is a solution that will work on linux, solaris, and windows 2000 - so it is perfect for your application.

A Standard for the Transmission of IP Datagrams on Avian Carriers

IP over Avian Carriers with Quality of Service

A Standard for the Transmission of IP Datagrams on Avian Carriers

IP over Avian Carriers with Quality of Service

We've just upgraded our network and are now fully RFC 2549-compliant nation-wide. Works just fine.

...laura

...because it's only an RFC, so you don't have to follow it.

That's not what RFC means, even though I know you're thinking "Request For Comments."

See the Status of this Memo section at the top of each RFC to determine whether it's an "Internet Standard" or "Internet standards track protocol" or "Experimental Standard" or "Historic" or some other category.

RFC 793 is "only an RFC" but your packets won't be routed if you don't follow it.

Chech out

RFC1178 / FYI0005: "Choosing a Name for Your Computer" for the IETF recommendations.

Sorry Lars but you are wrong.
see : rfc2616
Hypertext Transfer Protocol -- HTTP/1.1

3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions:
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;

"rtsp://" protocol, something only realnetworks software can understand

Wrong. RTSP is an open protocol. You can read RFC2326 here. Multiple implementations already exist, including an open-source one.

If you create an image and you don't want other people linking to it without context, then you need to learn about HTTP. If you are too stupid, then you should pay someone to do it for you. The simple solution is a script or web server hack that checks the HTTP headers for a referrer and denies all requests for images without a referrer pointing somewhere on your site.

Here, from the HTTP 1.1 RFC, the section on referrers. Any browser worth it's spit should provide the correct Referrer header.

14.36 Referer

The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained (the "referrer", although the
header field is misspelled.) The Referer request-header allows a
server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance. The Referer field MUST NOT be
sent if the Request-URI was obtained from a source that does not have
its own URI, such as input from the user keyboard.

Referer = "Referer" ":" ( absoluteURI | relativeURI )

Example:

Referer: http://www.w3.org/hypertext/DataSources/Overview.h tml
If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. See
section 15.1.3 for security considerations.

Here you are, there is a big chunk on security as well

The EU believes that because the root servers are not controlled and administered by one central authority, they are unreliable.

This is true, to an extent. Different and widely spread organizations run the root name servers, using different OS's, hardware configurations, and network connectivity.

And this is a Good Thing

Whoever in the EU (I suspect it's some ex-communist beaurocrat who loves centralized authority) thinks that things are bad now should read the RFC 2870, Root Name Server Operational Requirements and get a clue.

...while you're at it, give the secure machine a private IP address. That way, (most?) packets from the outside to that machine be dropped before you ever see them. One more layer of crap for a would-be intruder to get through.