Slashdot Mirror

We can argue about what that entails...

A lot of the stuff that traditionally goes in shell prompts is outdated or inappropriate for newbies. If you're using using the shell in a terminal window (as almost everybody does these days, especially newbies), you don't need email notification, time, CPU load, and a lot of other crap you can have in a GUI window. The name of the machine you're on is helpful is you're access a lot of different machines -- but most newbies won't do that. (Let's all sing the Telnet Song!) I like to have the command history number in my prompt, since that makes it easier to repeat a command that hasn't scrolled off the top of the screen yet. Then again, that's obsolete too, since any decent shell has lets you uparrow back to previous commands.

I used to have something to indicate my shell depth, so I wouldn't forget that I'd shelled out of another program. But I stopped shelling out when job control was invented -- not to mention Xterm windows.

I guess there's not a lot worth putting in the prompt any more. And what you do put should mostly be embedded in an escape string that puts it in the Xterm window. No, wait a minute, that's obsolete too -- most shells now let you define a hook -- an alias or a script -- that's run before each prompt. Makes more sense to put complicated commands there.

So probably you should just set the prompt to "% " and forget about it.

Same with the 'X-No-Archive:Yes' thing in Google groups.

4.7.5. USER-DEFINED-FIELD

Individual users of network mail are free to define and
use additional header fields. Such fields must have names
which are not already used in the current specification or in
any definitions of extension-fields, and the overall syntax of
these user-defined-fields must conform to this specification's
rules for delimiting and folding fields. Due to the
extension-field publishing process, the name of a user-
defined-field may be pre-empted

Note: The prefatory string "X-" will never be used in the
names of Extension-fields. This provides user-defined
fields with a protected set of names.

Now I like a good laugh as much as the next person

In gaming, this is a "tell". Whenever someone uses this phrase, it actually indicates a near-total lack of enjoyment of a good laugh as much as any number of randomly-selected "next persons".

Just lettin' you know. Humor has its place, and that place is any damn place you can find it in this sad scary crazy world.

Wrong. Read the RFC. The whole 127 is reserved, but only 127.0.0.1 is loopback.

bzzzzt. Time for an Anonymous coward to also learn something relatively useless today :-)

according to RFC 1166:

The class A network number 127 is assigned the "loopback" function, that is, a datagram sent by a higher level protocol to a network 127 address should loop back inside the host. No datagram "sent" to a network 127 address should ever appear on any network anywhere.

Source: http://www.faqs.org/rfcs/rfc1166.html

It should, but it doesn't. According to RFC 3330, the "ordinary" implementation only pays attention to 127.0.0.1. The whole 24-bit block is reserved for loopbacks, but the various Internet standards bodies made no requirement that implementations use it. The only enforced requirement is that such addresses don't appear in packets on the backbone/network.

Document your application, requirements, constraints, and system interactions (what the engineer does). Then write the code (what the coder does). What you will quickly learn is that it's better to be the engineer than the coder.

Interestingly there are a number of formal languages to do this, some of them rather similar to programming languages. For example you can use an algebraic specification language like CASL - it provides a structured way to define datatypes, operations on datatypes, and the axioms that the types and operations need to obey for the requirements to be met (For the mathematicians out there: an implementation is then a (many-sorted) universal algebra, and a specification is a presentation). There are things like refinement calculus and theorem provers to help you refine your requirements into an ever more specific specifications. Once that is done the actual programming is pretty much monkey work: there are extremely specific bounds on every datatype, every function, to the point where it is merely a matter just doing what you're told. The interesting part happen with the initial requirements specification and the refinement and design of the specification.

I happen to like CASL, and chose it here because the the syntax is similar to programming languages, but it is far from the only, or even the most popular specification language. You could try Z, or VDM, or B-method, or OBJ3, or any of the myriad other languages out there. Formal specification languages ought to be far more widely used than they apparently are. Isn't it about time more "software engineers" started paying attention to them?

Jedidiah.

Er, that's a nonexistent article. Fortunately, a Wikipedia search on "orthogonal" did lead to another article that does exist.

Beats the TCP-like pigeon spec RFC1149.

So, paying for any software is a bad thing? I don't care if they implement RFC 1149 for my gaming experience,as long as i like the game. Might as well say "buying a stupid piece of silicon that doesnt DO anything with out instructions!!"

As for the stats, you have an way to make money off of just yourself reporting stats to someone, please tell us more. I am sure if there was some sort of community/non-profit version we could all reply to that would be great but i don't know of any. Besides, the biggest value is to valve and their competitors and the data has been (to some extent) shared with the world,right? So the problem is.....??

And I am sure that there is no way to disable that kill-switch. Nope,never gonna happen. No one would every figure out a way around such a thing. You are so wise.

This doesn't prevent all network problems by any means, but it cuts down on lots of annoyances. You can prevent forged UDP packets and forged TCP SYN packets, so there are a number of attacks that don't work. (Forging TCP sessions was already much harder.) Forgery can still happen within a subnet, e.g. a packet claiming to be from 1.2.3.4 might be from some other machine at 1.2.3.0/24, but you can go find the right wire to look at, so you can trace problems reliably and add extra filtering/detection in the right place. Forgery can still happen on other ISPs that don't do spoof-proofing, but you can at least trace it if it's within your network and you can work with other ISPs to clean up their acts as well.

Not true! For example, they follow RFC 3514

Do remember that FidoNET, from July of 84, is a year and change older than Usenet, which properly starts during UUN's Great Renaming in 1986, and that some geezers still think it's better designed.

(Before anyone flips out that UUN was from 1979, please remember that the debate is over network architecture, and that UUN used UUX/UUCP; NNTP, which is the architecture to which parent refers, is first proposed in February of 1986, and doesn't see wide-spread use until late 87/early 88.)

OTP protocol ("One Time Password") use a dictionnary (from the S/Key protocol) to convert 64bit password into 6 pronounceable words.

This dictionnary could be a way of generating 64bits random password that could be easily remembered by your users by giving them this "6 words" version.

Anyway, always remember that your password may be "cryptographically strong" enough, but will never be "chocolatelly strong" enough...

OTP protocol ("One Time Password") use a dictionnary (from the S/Key protocol) to convert 64bit password into 6 pronounceable words.

This dictionnary could be a way of generating 64bits random password that could be easily remembered by your users by giving them this "6 words" version.

Anyway, always remember that your password may be "cryptographically strong" enough, but will never be "chocolatelly strong" enough...

IMAP's closer than you think. If you don't think SQL is relational, you certainly won't think IMAP is, but you can do more than most MUAs support. You can save arbitrary tags on email messages. You can execute surprisingly-sophisticated queries. I recently wrote some crude Jython scripts that use the JavaMail API to do queries like this:

to_me = OrTerm([HeaderTerm(header, "slamb@slamb.org")
for header in ["To","Cc","Bcc"]])
to_list = OrTerm([HeaderTerm(header, "")
for header in ["List-Post","List-Id","List-Archive"]])
msgs = sourceFolder.search(AndTerm(NotTerm(utils.to_me), utils.to_list))

(sorry about the indentation; ecode apparently doesn't like it.)

You have to read RFC 2060 to know all that IMAP can do.

Is that why my RFC 1149 packets keep disappearing?

I do, too.

Unfortunately, in the world at large when you mention X Windows you get a confused look as the person wonders if what you're talking about is either somehow related to Mac OS X or is a "Brand X" pale imitation of the wonderful brand name product that is genuine "Windows".

I suggest X.org get with the times.

You've heard of iSCSI for accessing SCSI disks over IP? It's cool. It's recent. It's what all the hipster and groovy people are into.

The next generation of X Windows should not be called something like X11R7, X12, or Y.

It should be called something like iVideo with its own RFC and an i so all the PHBs and IT journalists will know it's cool because it flows over the network, dammit.

[OpenGL hardware level performance is one checkbox item; the other is some infinite resolution support so SVG, PDF, etc. can be rendered without as much intermediate interpretation.]

"However, scalable fonts are, in the opinion of the Copyright Office, computer programs, and as such are copyrightable:

'... the Copyright Office is persuaded that creating scalable typefonts
using already-digitized typeface represents a significant change in the
industry since our previous [September 29, 1988] Policy Decision. We
are also persuaded that computer programs designed for generating
typeface in conjunction with low resolution and other printing devices
may involve original computer instructions entitled protection under the
Copyright Act. For example, the creation of scalable font output
programs to produce harmonious fonts consisting of hundreds of
characters typically involves many decisions in drafting the
instructions that drive the printer. The expression of these decisions
is neither limited by the unprotectable shape of the letters nor
functionally mandated. This expression, assuming it meets the usual
standard of authorship, is thus registerable as a computer program." 57
FR 6202.'"

By 15 years and the way the worlds going ( development of EMP bombs ect) have to fall back to (RFC2549)

Not that I'm cynical or anything ;)

The answer to this is very simple. It was a joke. It had to be a number, an ordinary, smallish number, and I chose that one. Binary representations, base thirteen, Tibetan monks are all complete nonsense. I sat at my desk, stared into the garden and thought `42 will do'. I typed it out. End of story.

Well, a bunch of searching leads me to believe the patent is trivial. Having stated that, it's worth mentioning that another patent (search for Stac on the page), 5,016,009, was also involved in the case, but I can't seem to find an actual copy of the judgement (it's probably on Lexis Nexus) to know how much basis it had on the ruling.

So, Microsoft never had a hold on the patent. It just happened to reinvent for a fourth time time (Waterworth, Ross, Gibson/Graybill, and Microsoft) the same idea. That's a pretty good clue that that patent shouldn't exist or be a basis for why Stac won. If you have any more information, I'd be glad to hear it.

Does anyone see the uncanny link between the Movie Brazil and the F/OSS - M$ Battle? I find it most prophetic that one of M$ bending points is in Brazil!

A quote from T.Gilliam on the FAQ http://www.faqs.org/faqs/movies/brazil-faq/

"What BRAZIL is really about is that the system isn't great leaders, great machinating people controlling it all. It's each person performing their job as one little cog in this thing and Sam chooses to stay a little cog and ultimately he pays the price for that." Sounds like the difference between M$ and F/OSS to me?

This has been addressed in RFC 3675

File Transfer Protocol -- the original "P2P" file sharing from the 1980's.

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

As the Internet was used mainly by the military and by universities back then, it was used to allow researchers to share published papers, research data, and software they had written.

That's why MGM v. Grokster is so bogus. P2P file sharing was one of the main purposes of the Internet (it wasn't to surf cnn.com).

http://www.pcworld.com/news/article/0,aid,120228,0 0.asp
http://www.eff.org/IP/P2P/MGM_v_Grokster

Which brings me to another pet peeve. I keep seeing news reports on various topics that say things like "Internet and e-mail access". What they really meant to say was "web and e-mail". HTTP is but one of many protocols that run on the Internet. "The Internet" is much bigger than just "the web".

To make that even more clear, prior to the web, when you signed up to the Internet, you would expect "e-mail and UseNet". Now you expect "e-mail and web and maybe UseNet if the ISP is a) nice and b) retro".

It just illustrates that Internet protocols come and go. FTP was a file sharing protocol. Grokster, Kazaa, etc. are just new file sharing protocols.

UseNet itself is actually also based on peer-to-peer technology. UseNet is the globally distributed message board system. groups.google.com archives UseNet posts, but they are just one of thousands of UseNet servers across the globe collaborating to provide the service. UseNet servers talk to each other as "peers" to synchronize their message postings.

The whole nature of the Internet was originally "peer-to-peer". But two things have come along to keep that concept out of the minds of most Internet users:

a) Web technology, which is more client-server than peer-to-peer. The popularity of the HTTP protocol has made it seem to most people that the web is the Internet, and thus most people think that to participate on the Internet means you are supposed to "log in" to some "official" computer (e.g. browsing to cnn.com)

b) Dynamic IP. The inventors of the Internet thought that 2 billion IP addresses was enough for the world. Well, we've run out, and so now when you get an Internet account you no longer get your own "static" IP address. Instead, you get a "dynamic" IP address. That makes it impossible to register a domain name (like underreported.com) to your own computer at home. Instead, you have to pay a "hosting provider" to use their computer running on their network that happens to be privileged enough to have static IP addresses. In the old days, everyone's computer handled their own e-mail, their own FTP server, etc. FTP is really only effective with static IP addresses. The rise in popularity of so-called "P2P file-sharing apps" is due in part that they were built to work with dynamic IP addresses (because they advertise themselves on a custom protocol as opposed to relying on the DNS (Domain Name System, where names like underreported.com are recorded along with their static IP addresses)).

Easy:

Build a PGP based site identity verification infrastructure deployed in the DNS distributed style with trusted root servers.

Add an automatic PGP site identity verifaction to web browsing (IE) and email (Outlook,Exchange) which uses that infrastructure.

Make all the IP needed to implement same F/OSS and pay for the hardware and web connections of the root servers, which would be serving mostly tier 1 and 2 internet carriers. MS could even use the existing DNS and PGP code bases.

Improve the security of MS-Win software so that its at least as difficult to zombie a Win system as it is a Linux system.

Ahem, for those who think that Win systems are zombied more frequently simply because there are more of them, please do some googling and look at all the articles describing how Microsoft's design decisions are the actual reasons why MS systems are the chief virii carriers and propagators on the net.

Here is one:

http://linuxmafia.com/~rick/faq/index.php?page=vir us#virus4/

And an excellent overview of the design/architectural differences beween OSes is here:

http://www.faqs.org/docs/artu/ch03s02.html

Why can't they outlaw April Fool's things on the internet? I rather enjoyed the RFC's in the old days (Pigeons HAH!) and the new Klingon thing, but it's really getting tired.

Looking forward to tomorrow ...

Personally, I much preferred the more technical ones like:

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

Its exactly 2 years since that rfc for setting an evil bit in packets appeared, but nothing happened since then ?
http://www.faqs.org/rfcs/rfc3514.html

Sure you need to vacuum the tables with frequent insert/update/deletes but thats the price of REAL ACID. It's not like cron jobs are that hard to setup anyway.

Just filter packages with the evil-bit set.

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

Anybody who understands this will have a problem with a PDF viewer that is anywhre close to that big. Contrast that with the size of xpdf granted this has more "features" but still the contrast in size there will tell almost anybody who groks software that something is *very* wrong with the Adobe version.

Banks are being increasingly required to "know your customer", including getting photo id and collecting SSNs. Just about any business that pays you money needs to collect an SSN - it used to be possible to get a non-interest-bearing checking account without one, but I don't think you can do that any more in the US, at least not at a regular bank.

And yes, it's police-state stuff, quite deliberately.

I have often looked to MySQL's html documentation as a shining example of what documentation should be like. It has a pretty good API, too. I usually haven't the time to do a really knock-up job of my own documentation, but I do try to look at MySQL's for my general approach, including the format (html). Here's an example of some of my documentation. I borrowed some pointers from the standard UNIX man page format, too, because it's been in use for a long time and developed into something reasonably complete and useful.

Another good example (imo) is the RFC which defines the NNTP protocol, rfc-977.

Know your audience -- the HOWTO I wrote was primarily for nonprogrammers with rudimentary knowledge of UNIX command line use (waybackup's primary expected users), but also for programmers who might be trying to debug or extend my code.

The most important thing with a SDK or any other tool, in my opinion, is use it a lot before publishing it, or even considering its development complete. Don't just come up with artificial examples, but actually use it internally to solve real-world problems. Your developers will unavoidingly find really annoying little problems in need of fixing, and come up with time-saving functions (perhaps just wrappers around already-existing API functions) which might need to be added to the SDK. Perhaps there's a function which seemed reasonable at the time, but in actual practice leads to runaway memory consumption. Maybe there are several functions which often get used together, but require the programmer to keep track of parameters which could get hidden internally instead. A nice long beta test, with the expectation of many programmer hours spent in reaction to user-reported errors/suggestions, is also often a good thing.

In fact, as a programmer I usually tailor my development effort towards getting something minimally useful first, and then actually use it, and let my use define further development. Features that sound good "on paper" are often a waste of time to develop because they don't actually get used. Also, thinking real hard at code does not necessarily make it better than code which has been shaped by real-world usage.

Anyway, I'll shut up now. Good luck with your SDK!

-- TTK

Please stop propagating the myth of classful routing. 172.16.0.0 is neither class B, class C, or any other class. It is 172.16.0.0/12. This is CIDR (Classless Inter-Domain Routing). Please see RFC 1519 about CIDR and RFC 3330 about 172.16.0.0/12 and other special use IP addresss.

Please stop propagating the myth of classful routing. 172.16.0.0 is neither class B, class C, or any other class. It is 172.16.0.0/12. This is CIDR (Classless Inter-Domain Routing). Please see RFC 1519 about CIDR and RFC 3330 about 172.16.0.0/12 and other special use IP addresss.

You might want to read Esr's Art of Unix Programming, specially chapter 5 on data formats
Here's what he says about XML files :
The most serious problem with XML is that it doesn't play well with traditional Unix tools. Software that wants to read an XML format needs an XML parser; this means bulky, complicated programs. Also, XML is itself rather bulky; it can be difficult to see the data amidst all the markup.

So one follows the Unix Philosophy and the other doesn't. I know which I would rather use.

Wikipedia, Wikibooks, plus various wikis and websites all over the web for more detailed texts, like TLDP, Internet FAQ Archives etc. Good luck!

I note that the two email addresses contained in that linked page are in plain, non-munged text. His poor secretary must have to wade to tons of spam due to his failure take simple precautions.

There's a lot of people that don't follow the Netiquette Guidelines specifically when responding threads; they don't cut the things that don't need to be included on the response. And this was the big cause of having a lot of space wasted when storing email.

Wow. You invoked Godwin's Law before most of us dumb uninformed Americans were even awake. Not that we could read your loony rant because we're illiterate.

Perhaps it was a clever reverse troll? You whined about total ignorance and mischaracterization of the left, and then spun around and ignorantly mischaracterized the American right. Intentional or not, it was an excellent illustration of the mindless partisan idiocy and distortion that you claim to dislike, at least when it's applied to the left.

I was trying to work out what effect or side effects this could have. From /usr/src/linux/Documentation/filesystems/proc.txt, it references RFC1323, which says "The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences)."
I'm going to do some tests with it enable, and disabled, and see if I can find any difference. Google didn't turn up anything in the first few results one way or the other.

The WinRar license states:
Neither RAR binary code, WinRAR binary code, UnRAR source or UnRAR binary code may be used or reverse engineered to re-create the RAR compression algorithm, which is proprietary, without written permission of the author.

and the source code:
The unRAR sources may be used in any software to handle RAR archives without limitations free of charge, but cannot be used to re-create the RAR compression algorithm, which is proprietary. Distribution of modified unRAR sources in separate form or as a part of other software is permitted, provided that it is clearly stated in the documentation and source comments that the code may not be used to develop a RAR (WinRAR) compatible archiver.

So the guy is basically paranoid about keeping his "trade secret" a secret, which makes perfect sense from a business perspective. As far as FOSS is concerned, he even presents decompression code free for all to use.

How much of a problem is a proprietary compressor if the end-user never has to deal with it? Is it a problem if you can't create the archives, as long as you will have free access to use them?

I see it like gzip: gzip is defined by a couple of RFCs, and it's just a file format and a specification for decompressing the data. As long as you end up with something in .gz format, it doesn't matter if you use an open algorithm or a supersecret-proprietary-patented-licensed algorithm to get there. The decompressor is the same in either case, and you already said that you have a LGPL version of the RAR decompressor.

The WinRar license states:
Neither RAR binary code, WinRAR binary code, UnRAR source or UnRAR binary code may be used or reverse engineered to re-create the RAR compression algorithm, which is proprietary, without written permission of the author.

and the source code:
The unRAR sources may be used in any software to handle RAR archives without limitations free of charge, but cannot be used to re-create the RAR compression algorithm, which is proprietary. Distribution of modified unRAR sources in separate form or as a part of other software is permitted, provided that it is clearly stated in the documentation and source comments that the code may not be used to develop a RAR (WinRAR) compatible archiver.

So the guy is basically paranoid about keeping his "trade secret" a secret, which makes perfect sense from a business perspective. As far as FOSS is concerned, he even presents decompression code free for all to use.

How much of a problem is a proprietary compressor if the end-user never has to deal with it? Is it a problem if you can't create the archives, as long as you will have free access to use them?

I see it like gzip: gzip is defined by a couple of RFCs, and it's just a file format and a specification for decompressing the data. As long as you end up with something in .gz format, it doesn't matter if you use an open algorithm or a supersecret-proprietary-patented-licensed algorithm to get there. The decompressor is the same in either case, and you already said that you have a LGPL version of the RAR decompressor.

The protocol section in the packet header is marked 30. As such it should follow the rfc969 guidelines.

"How do you tell bad bits of html from good bits?"

Check the evil bit in the TCP/IP header.

Why not 1 G of P2P with FTP ?

IIRC, FTP (TCP 21) isn't P2P. RTFM: RFC 959.

Unlike the evil bit, the internet community might actually find a use for this one.

It's called a Well Known Service record (WKS). Actually, rfc 1033 defines the WKS a little differently from what you've purposed. Either way, the whole concept would only make blocking a given port harder, not impossible. If the world can read your DNS records to determine which port the services they need are on, so can your ISP.

Better still, use the avian carrier protocol to transmit packets to google. If you select carriers attractive enough, I'm sure it will distort google's search technology.