Slashdot Mirror

Surprisingly enough, it would be even slower than RFC 1149, I imagine. . . .

Far more offensive to me is that they use csh as a scripting language. This is absolutely unacceptable.

here

Why "bust" you for 28x when they could claim 1563x ???

Nah, in this case RIAA would define the "average" connection that people have as "avian carrier".

Of course, when they need to show just how advanced and widespread piracy is, then the "average" connection will be OC-192, downloading and serving 24/7.

Why put access points on birds when we have RFC 1149?

Ghastly protocol. Glad it failed.

Are we starting this story again? The fact is that there are a lot of files that CAN NOT be compressed. Period.

See the rationale about it, thanks to the guys at news:comp.compression. There you will find the story behind some scams involving 'infinite' compression or 'universal' compressors.

Fh

Interesting, I didn't know there was such a Rule/ Law of Usenet before your comment. I guess if you start with the Nazi subject your are exempted. ;-)

At any rate, it sure seems like access to a critical top level DNS should be filtered to a big white list of mirror machines, which could then handle general purpose inquiries.

3.3.4 A 'hidden primary' server, which only allows access by the
authorized secondary root servers, MAY be used.

The DOS command line sucks. (...) The DOS command line is a stripped down, sodomized version of most *nix shells. If you liked DOS, install your favorite UNIX variant, and try out bash. (Feel free to use ksh or csh to your liking.)

I basically agree with all of your points (from this post, as well as the rest of this thread), except that I'd suggest (and, in fact, I have already suggested) him trying out Cygwin before installing a full Unix distribution, and use the Bash under Windows instead the DOS command line. I would also not suggest using csh (mostly because of issues pointed out by Tom Christiansen in Csh Programming Considered Harmful). For his first non-Microsoft shell experience, I strongly recommend Cygwin version of Bash under his existing setup of Windows. Of course, GNU under Windows is not my final recommendation (since I use Debian even on my desktop) but I think it's a good start and it needs very little time to try it out.

Csh Programming Considered Harmful, by Tom Christiansen.

The Ten Commandments for C Programmers (Annotated Edition) by Henry Spencer.

Spam predates the web. It was described as a problem
in rfc 706 On The Junk Mail Problem by Jon Postel
in 1975. A telling quote is:

"The services denied are the processor time consumed
in examining the undesired messages and rejecting
them"

which remains the chief argument against the
legality of spam.

SCSI over IP sounds real good

Heh, there's also IP over SCSI (see RFC-2143).

I guess if you're really perverse you could run SCSI over IP over SCSI over IP over ... well, you get the idea.

http://www.faqs.org/faqs/astronomy/faq/part2/secti on-22.html
http://sm3a.gsfc.nasa.gov/messages/676.html
http://www.redzero.demon.co.uk/moonhoax/telescopes .html

Just to name a few.

You are correct... The following are for private IP addresses (e.g. for NATing):

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

This is according to RFC 1918.

B*B,
-Smoke.

Sometimes people use t?csh for root's shell for a few reasons: it's installed in the base system of most Unices, it's typically statically linked, and it has more built-in commands. Argubly these make it superior if there are system disasters, though you could solve that by putting bash statically linked in /bin and making sure those non-builtins are also statically linked in /bin.

A couple of URLs quickly found on Google:
http://www.faqs.org/faqs/ai-faq/neural-nets/part3/ section-7.html
http://www.csse.monash.edu.au/courseware/cse5230/a ssets/images/week09.pdf

Also, any decent AI/machine learning textbook ought to cover the topic.

-DVK

While I hope to be a little more eloquent than our anonymous friend, he is right, to a point.
LEGO-faq

Matthew Miller, mattdm@mattdm.org, added:
The above quote from the catalog is often cited as evidence for "Lego"
as the proper plural, but in fact that is misreading it. Trademark law
in the US at least is easiest if the trademark is used as an
_adjective_. The point they're trying to make is that you should say
"LEGO Bricks", rather than calling the product itself either "Legos"
_or_ "Lego".

In fact, they seem to assume that "LEGOS" is the natural plural, since
that's the only one they bother to correct. So, in formal usage, both
"Lego" and "Legos" are wrong. To me, that means people shouldn't make
such a big deal about it in informal use!

Oh the happy memories of myself (british), another brit and an australian bugging our american boss for hours about the finer points of the plural lego.
We never did get to all go for a day out to legoland :(

I wonder if Godwin's law also applies to Mussolini? After all, if you've seen one WW2 fascist dictator, you've seen them all...

You know, I seem to have encountered mention of Hitler or Nazis in several of the threads I've browsed in the last week or two.

It just made me wonder if Godwin's law also applies to /.?

And if it does, what does it mean when those posts are modded up?!?

Mike

• AIX is dying.
• AmigaOS is dying.
• BSD is dying.
• BeOS is dying.
• CPM is dying.
• DOS is dying.
• FreeBSD is dying.
• GNU Hurd is dying.
• HP-UX is dying.
• IRIX is dying.
• Inferno is dying.
• Linux is dying.
• LynxOS is dying.
• MINIX is dying.
• MacOS is dying.
• Mach is dying.
• MicroC/OS is dying.
• NachOS is dying.
• NeXT is dying.
• Nemesis is dying.
• NetBSD is dying.
• NetWare is dying.
• OS-400 is dying.
• OS-9 is dying.
• OS/2 is dying.
• Oberon is dying.
• OpenBSD is dying.
• Palm OS is dying.
• Plan 9 is dying.
• pSOS is dying.
• QNX is dying.
• RTEMS is dying.
• SCO is dying.
• Solaris is dying.
• SunOS is dying.
• TRON is dying.
• ThreadX is dying.
• TinyOS is dying.
• Unix is dying.
• VMS is dying.
• VxWorks is dying.
• Windows 2000 is dying.
• Windows 3.11 is dying.
• Windows 95 is dying.
• Windows 98 is dying.
• Windows CE is dying.
• Windows ME is dying.
• Windows NT is dying.
• Windows XP is dying.

"The operating system loader, BIOS, or other firmware required at boot time or when installing the operating system would generally not be considered part of the operating system, though this distinction is unclear in the case of a rommable operating system such as RISC OS. The facilities an operating system provides and its general design philosophy exert an extremely strong influence on programming style and on the technical cultures that grow up around the machines on which it runs.

The comp.os.research FAQ makes the following distinction between micro- and macrokernels:
"A recurrent topic of discussion in this newsgroup has been the comparison between microkernel (for example Mach and QNX) and `macrokernel' (traditional Unix) operating systems. The basic notion of a microkernel consists of devolving as much functionality as possible into processes rather than the kernel itself; different systems take different approaches to implementing this.

For example, some systems (such as Mach) leave device drivers in the kernel, and place higher-level services (such as file systems) outside; others (such as QNX) move device drivers outside of the kernel.

However, anecdotal evidence [93-03-03-07-56.52] suggests that the distinction between microkernel and monolithic architectures is becoming more blurred as time goes on, as the two advance. For example, most modern monolithic kernels now implement multiple threads of execution and fine-grained parallelism. Architecturally, this approach begins to appear similar to a microkernel with several kernel-space processes working from shared memory.

As an aside, people often complain that the Mach system can't be a `real' microkernel, because it is so large (at least, this is the argument most frequently cited). However, I have been told that automatically-generated code stubs contribute very significantly to the size of the kernel, and that some size reduction would be likely if MIG (the stub generator) produced better code. [Can someone from CMU comment on this?] As mentioned above, the leaving of device drivers in the kernel also contributes to Mach's size.

Debating microkernels versus monolithic kernels on the basis of kernel size misses the central, architectural point. In the same way as the point of a RISC processor is not to minimise the instruction count, but rather to make a different tradeoff between what is implemented in the processor instruction set and what is implemented in other ways, the microkernel architectural issue is to determine which services are implemented in the microkernel, and which services are implemented external to that microkernel. By making appropriate choices here, the goal is to enhance various OS attributes in a manner that might not be addressable with a monolithic kernel OS. System attributes such as performance, flexibility, realtime, etc. are all variables which are taken into account.

I like the sound of what you say, and I generally agree, but I'd like you to consider the following observations in a reply, if you would.

You say:

Fact is, all security is obscurity. Security rests on the notion of a shared secret. Some key that both you and the other guy know.

This isn't exactly true of public-key cryptographic systems, is it? I mean, I suppose you could consider the public key as the "shared secret", but the point of it is that it can be public. On the other hand, the address (whether it be a memory location or i-node number or URL) of a byte range (protected by encryption or not) could be considered privileged information as a matter of policy, and would then constitute the shared secret of which you speak. Unfortunately, I don't know if this argument would be accepted by everyone. Let me try to reason along the same lines as you did and see where that takes us.

• Writing memory locations that were not intended for user consumption can be achieved by buffer overflows; although the memory write is (or can be) the result of doing something completely normal (like, for example, writing data to a socket) it is almost certainly illegal resource usage.
• Running unauthorized system commands can be achieved by composing an HTML form that will trick the CGI script interpreter; although the execution of the command is the result of a perfectly normal HTTP transaction, it may also be an illegal appropriation of services.

Now, given that some instant messaging client has used buffer overflows as a normal part of its operation (which one? I forget) and that programmable web interfaces (where, depending on how you look at it, you're supposed to do stuff that the service provider didn't anticipate) are all the rage now, does the foregoing still hold?

I'm actually quite relieved to see that they don't include csh. I think that's just good sense. As for pdksh, I doubt if even BSDers use it very often, so it probably fails the widely-used test. I actually know of more people that use ash (recently renamed dash), which is originally from NetBSD, but is now found on many other systems (Linux, FreeBSD, etc.)

The FAQ definition of strong AI is straightforward enough. It's possible to read Searle and get all tangled up in philosophical issues, like "is it really thinking." All I mean by "strong AI" is getting into the ballpark of human mental performance across a broad spectrum of activities. We do not have a clue on how to do that.

Storing the year as a +- offset from 1970 would allow a range from 1842 to 2097 and would only take up ONE BYTE of storage compared to storing two characters (taking up two bytes) giving a range of 1900 - 1999.

At considerable cost in the work required to perform certain operations (such as displaying) on the year. Remember that data size was not the only consideration in those days; code size and processing time were also major issues. Granted, many of the Y2K problems were probably due to laziness ("nobody will still be using this stuff in 30 years, let's just leave the 19 as constant"), but the two-digit year was probably the best compromise between data size and processing complexity at the time many of those programs were written.

And how do you know that the computers in question used 8 bits per character? (I don't, either, but there are some coding systems, such as EBCDIC, that use other numbers of bits, and some systems, like the PDP-8, that had e.g. 12 bits per memory unit; in fact, the PDP-8 FAQ mentions that many PDP-8 programs packed two 6-bit characters into one 12-bit word.)

Where each canister would contain what... an XML document?

There was a proposal to do something like this by setting up a brand new country, on the assumption that no existing country would ever allow this to happen within their borders. The new country was to be called Oceania, and was to be built in the Carribeans. There is also a FAQ for it.

If you want to know more about UTF-8, see RFC 2279.

Your referenced faq page says nothing about the rate of expansion accelerating. Would you like to give us a better reference which demonstrates your point?

(text of page, for the click-impaired)

I.11. Are galaxies really moving away from us or is space-time just expanding?
This depends on how you measure things, or your choice of coordinates. In one view, the spatial positions of galaxies are changing, and this causes the redshift. In another view, the galaxies are at fixed coordinates, but the distance between fixed points increases with time, and this causes the redshift. General relativity explains how to transform from one view to the other, and the observable effects like the redshift are the same in both views.

> if the "big crunch" theory is correct,

It's not. Astronomers have known for a while that the universe was expanding, but didn't know the rate. They recently discovered that the rate was accelerating!

Cheers

> if the "big crunch" theory is correct,

It's not. Astronomers have known for a while that the universe was expanding, but didn't know the rate. They recently discovered that the rate was accelerating!

Cheers

With this decision they will apparently be deciding if and when an actual non-profit organization can have a .org domain(what the top-level domain was designed for) and stop companies from buying .org addrs to go with their net and com ones.

ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non-government organizations may fit here.

if your md5 is x length long and your file is 10x length, then there are 9x as many other possibilities for the content of the file to give the same md5 sum. in other words, md5 can be Spoofed by adding random bits to the end(replacing legit bits however) until one gives the same md5 as another.

Sure, but how do you figure out what random bits to add? MD5 is cryptographically secure. See RFC 1321:

It is conjectured that the difficulty of coming up with two messages having the same message digest is on the order of 2^64 operations, and that the difficulty of coming up with any message having a given message digest is on the order of 2^128 operations.

Hang on a sec... this guy says he has a revolutionary new encryption algorithm that's as secure as a one-time pad?

Quite right. I think this guy had better think twice before dropping any capital on his "revolutionary" idea. Consider that rijndael *and* serpent -- algorithms developed by some of the best crypto folks in the world -- have recently both been partially compromised. Who knows, maybe the OP is a super-genius...

Moreover, I'm no expert, but since when is a true one-time pad vulnerable to known-plaintext attacks?! (Interested readers -- and the original poster -- are referred to the cryptography faq, esp. the section entitled "Why is a one-time pad secure?")

IMHO, the OP should use one of the above-mentioned cheap/free methods to establish his algorithm (the encrypted timestamp thing sounds pretty cool), and then open-source it for peer review. As "blibbleblobble" points out, especially in crypto, nobody's gonna take this seriously anyway without a lot of scrutiny. And that means it would be a long time before any of that $20,000 came back home...

Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. It's not even hard. What is hard is creating an algorithm that no one else can break, even after years of analysis. And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around.

6. Don't patent the cipher. You can't make money selling a cipher. There are just too many good free ones. Everyone who submitted a cipher to the AES is willing to just give it away; many of the submissions are already in the public domain. If you patent your design, everyone will just use something else. And no one will analyze it for you (unless you pay them); why should they work for you for free?

Gmanske.

Okay, I'll reply not just to feed the trolls but also for someone that might not know (like my relatives that send 2.1MB bmp files)

JPEG is a lossy compression. Depending on the level of compression and the content of the original photo, you will get a wide variety of results.

I highly suggest reading the JPEG faq for more details or checking Google for the right format that best suits your need.

Just what exactly do geeks have against the Routing Information Protocol?

I think lspd might have it right when he quotes a copyright faq as saying "With one exception, works of the United States government are public domain. 17 U.S.C. 105. The only exception is for standard reference data produced by the U.S. Secretary of Commerce under the Standard Reference Data Act, 15 U.S.C. 290e."

The JPL can do this because they're a government contractor. All's fair in that case. I only brought up this offtopic question because I didn't realize that the JPL wasn't a gov't org. I hadn't read the article.

I imagine patents and copyrights by gov't employees could easily be governed by differennt laws.

On a side note, everyone knows that if a CEO gives away a part of the company in a manner that is obvioiusly not the most beneficial to the shareholder value, he can be sued, held criminally liable, and thrown in jail. Wouldn't it be nice if we could do that to politicians? Even if only in the most egregious cases? Makes me fantasize about the Singaporean meritocracy... if it were combined with a massive bill of rights.

From what I've read,
"With one exception, works of the United States government are public
domain. 17 U.S.C. 105. The only exception is for standard reference
data produced by the U.S. Secretary of Commerce under the Standard
Reference Data Act, 15 U.S.C. 290e."

But this only applies to things produced by the federal government. If it's a work produced by someone else (university, advertiser, etc) and the federal government licenses it, it doesn't become public domain. So those Sept 11th commercials are most likely not public domain, and university research done with federal money is not necessarily public domain.

• AIX is dying.
• AmigaOS is dying.
• BSD is dying.
• BeOS is dying.
• CPM is dying.
• DOS is dying.
• FreeBSD is dying.
• GNU Hurd is dying.
• HP-UX is dying.
• IRIX is dying.
• Inferno is dying.
• Linux is dying.
• LynxOS is dying.
• MINIX is dying.
• MacOS is dying.
• Mach is dying.
• MicroC/OS is dying.
• NachOS is dying.
• NeXT is dying.
• Nemesis is dying.
• NetBSD is dying.
• NetWare is dying.
• OS-400 is dying.
• OS-9 is dying.
• OS/2 is dying.
• Oberon is dying.
• OpenBSD is dying.
• Palm OS is dying.
• Plan 9 is dying.
• pSOS is dying.
• QNX is dying.
• RTEMS is dying.
• SCO is dying.
• Solaris is dying.
• SunOS is dying.
• TRON is dying.
• ThreadX is dying.
• TinyOS is dying.
• Unix is dying.
• VMS is dying.
• VxWorks is dying.
• Windows 2000 is dying.
• Windows 3.11 is dying.
• Windows 95 is dying.
• Windows 98 is dying.
• Windows CE is dying.
• Windows ME is dying.
• Windows NT is dying.
• Windows XP is dying.

"The operating system loader, BIOS, or other firmware required at boot time or when installing the operating system would generally not be considered part of the operating system, though this distinction is unclear in the case of a rommable operating system such as RISC OS. The facilities an operating system provides and its general design philosophy exert an extremely strong influence on programming style and on the technical cultures that grow up around the machines on which it runs.

The comp.os.research FAQ makes the following distinction between micro- and macrokernels:
"A recurrent topic of discussion in this newsgroup has been the comparison between microkernel (for example Mach and QNX) and `macrokernel' (traditional Unix) operating systems. The basic notion of a microkernel consists of devolving as much functionality as possible into processes rather than the kernel itself; different systems take different approaches to implementing this.

For example, some systems (such as Mach) leave device drivers in the kernel, and place higher-level services (such as file systems) outside; others (such as QNX) move device drivers outside of the kernel.

However, anecdotal evidence [93-03-03-07-56.52] suggests that the distinction between microkernel and monolithic architectures is becoming more blurred as time goes on, as the two advance. For example, most modern monolithic kernels now implement multiple threads of execution and fine-grained parallelism. Architecturally, this approach begins to appear similar to a microkernel with several kernel-space processes working from shared memory.

As an aside, people often complain that the Mach system can't be a `real' microkernel, because it is so large (at least, this is the argument most frequently cited). However, I have been told that automatically-generated code stubs contribute very significantly to the size of the kernel, and that some size reduction would be likely if MIG (the stub generator) produced better code. [Can someone from CMU comment on this?] As mentioned above, the leaving of device drivers in the kernel also contributes to Mach's size.

Debating microkernels versus monolithic kernels on the basis of kernel size misses the central, architectural point. In the same way as the point of a RISC processor is not to minimise the instruction count, but rather to make a different tradeoff between what is implemented in the processor instruction set and what is implemented in other ways, the microkernel architectural issue is to determine which services are implemented in the microkernel, and which services are implemented external to that microkernel. By making appropriate choices here, the goal is to enhance various OS attributes in a manner that might not be addressable with a monolithic kernel OS. System attributes such as performance, flexibility, realtime, etc. are all variables which are taken into account.

arg..

why is this mod'ed as insightful? its absolute waffle. Poster hasnt a breeze about how inter domain routing works.

"With a heirarchical routing system like what TCP/IP uses, it can pretty much only go upstream to the backbone."

Eh? Since when is TCP/IP hierarchical? For that matter, wtf has TCP got to do it? (other than that some routing protocols use TCP). backbone? what backbone? Show me where the internet has a backbone. (hint: it doesnt).

"It is possible for a network to be designed so that there's no backbone, and the data can be routed wherever there are open connections"

no sh$t sherlock. What an amazing idea. I wonder if the guys that came up with BGP thought of it before you. And I wonder if anyone actually uses it. (hint: the entire internet).

"Such a system would have higher latency, because it would have more hops"

oooh.. ok.. why's that then?

"but the bandwidth could be okay, if _everybody_ runs fiber to the house nextdoor."

ah... so if everyone used fibre things'd go faster? Damn you should work for an ISP, mine are still trying to persevere with RFC2549 links to all their peers.

"TCP/IP won't work, because it can't
do routing in that kind of environment;some kind of routing protocol would have to be devised that understood the topology of such a network"

gosh good point, and may i refer you the BGP link above again?

"The really major problem with such a system is, how much do you charge your neighbors to
route their data, and what about the people whose data your neighbors are routing (through you), and so on?"

Hmm.. tricky one that. I believe some people are though trying their best to solve that one. (namely the lawyers who draw up contracts, and the accounts dept. of ISPs). Ie, yes, you pay the people you connect to depending on your comparitive standing (ie customers and traffic carried). If one is small and the other big, well why the small one generally pays the bigger one. Why one would almost call the smaller one a customer of the larger one. (there's a thought, you could run a business along these lines!). If the two are of equal comparitive standing, and can both agree they are, then they might peer with each other for free. For further discussion on this i really should direct you to the legal and accounting depts. of any decent sized (guess what?) ISP.

In fairness, what you describe is actually generally how the internet works if you substitute your neighbours for ISPs / v. large organisations, its just i'm in a sarcastic mood, and you have a lot of reading up to do. sorry.

OMFG! You DON'T see a problem with SMTP?!?! What RFC did you read? The very very first one?!?! (Ref.)

Part of the reason that SMTP does NOT work is because no one strictly follows it. They don't strictly follow it because it has GAPING holes in it that spammers have been using for years. (If you need an example, find a mailserver that actually responds truthfully to a VRFY cmd or RCTP TO for that matter) There is absolutely no reason to adhere to a standard that no longer encompasses the needs of the bigger picture.

Thank god they follow the MIME/OpenPGP standard! Now maybe us Sylpheed users will be able to decrypt email from non-Sylpheed users without having to jump through a slew of goddamn copy-to-clipboard hoops.

Email client developers, take note. Please don't reinvent the wheel. It only slows down adoption of encryption.

Given that the server is slashdotted, here are a few facts about pseudo-random number generators:

What!?!
Youe wireless isn't RFC 2549 compliant?

To argue that this is wrong because of defeating the DVD CSS in a DMCA-defying act is like arguing it's suddenly O.K. to roast Jews because Nazis in power passed a law saying so. (Yes, yes, Godwin's Law, and the concentration camps' purpose was somewhat hidden from the populace, so the analogy isn't perfect).

For the information of those, like me, who had never heard of Godwin's Law, it states: "As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one."

I guess the birds will need tiny spacesuits and rocket packs to make it back and forth.

Incoming interstellar hen!

Actually, that's kind of the textbook division between weak and strong AI. Even if strong AI is possible, a strong AI solution is decades to centuries away.

The value of weak AI is that it can solve lots of neat problems _now_, and can be trained to do many more. For example, the scientists mentioned are creating an awari program that can play a perfect game, which would be invaluable to people learning to play awari :)

I don't quite understand why a big lookup table is an important step for AI. Humans don't play games by checking every possible move and picking the best one and never will.

Not all people consider AI the quest for human-like intelligence ... some consider it the quest for intelligence. Especially because the human brain isn't really rational in the ways computers are (its strengths lie in other areas. The human brain, for example, probably couldn't play a perfect game of awari.

And I think the 'big lookup table' is somewhat novel because the methods used to create it and analyze it were novel, not because a giant lookup table is really fantastic. I don't believe deep blue really used complicated concepts in AI, but the fact that a computer could be put together that could beat a grandmaster is pretty impressive.

Beer is free as in speech.
Here is the source

To compile beer, you don't even need a computer, only household equipment.