Slashdot Mirror

We run linux but wanted remote bios, lilo and boot messages. I have configured our servers for serial output using this howto:
http://www.faqs.org/docs/Linux-HOWTO/Remote-Serial -Console-HOWTO.html

I then plan to connect a cheap 4 port serial to ip unit (around 200 bucks):
http://www.lavalink.com/index.php?id=263

Providing remote (pre network) access to 4 machines for 200 dollars. Is there a cheaper solution for four machines?

I have adopted PHP as my shell scripting language of choice

Ask and you shall receive. Behold SRV

The NAT problem got resolved by UDP encapsulation ("NAT-T" = NAT traversal, after years of being a draft finally published 5 days ago as RFC) got implemented by most vpn software during the past two years (= too late).

Hybrid auth means: peer A ("the server") authenticates itself to peer B ("the client") through asymmetric methods (like an RSA keypair and a X.509v3 cert). Peer B chooses a random symmetric session key and encrypts it for A, this sets up an encrypted tunnel. Inside this tunnel, B authenticates itself to A using simpler techniques like challenge-response or even clear passwords. Allmost all personalized TLS/SSL protected services (https, pop3s, imaps, ...) work this way: Servers has a cert, client has a password. Easy to admin, easy to deploy, easy to rollout.

But with IPsec/IKE/ISAKMP you have to choose between shared secrets (bah!) or rolling out keypairs to all peers. And like all other protocols requiring all peers to be part of a PKI (PGP, S/MIME, SSL+certs on both sides) this slowed down propagation strongly.

There is an IETF draft "A Hybrid Authentication Mode for IKE" which is adopted my more and more implementations right now (= far too late). Cisco is now pushing it because of the failure of their own "group password scheme" (of course they name it differently: "Mutual Group Authentication").

Man, why did they wait so long?

/graf0z.

The NAT problem got resolved by UDP encapsulation ("NAT-T" = NAT traversal, after years of being a draft finally published 5 days ago as RFC) got implemented by most vpn software during the past two years (= too late).

Hybrid auth means: peer A ("the server") authenticates itself to peer B ("the client") through asymmetric methods (like an RSA keypair and a X.509v3 cert). Peer B chooses a random symmetric session key and encrypts it for A, this sets up an encrypted tunnel. Inside this tunnel, B authenticates itself to A using simpler techniques like challenge-response or even clear passwords. Allmost all personalized TLS/SSL protected services (https, pop3s, imaps, ...) work this way: Servers has a cert, client has a password. Easy to admin, easy to deploy, easy to rollout.

But with IPsec/IKE/ISAKMP you have to choose between shared secrets (bah!) or rolling out keypairs to all peers. And like all other protocols requiring all peers to be part of a PKI (PGP, S/MIME, SSL+certs on both sides) this slowed down propagation strongly.

There is an IETF draft "A Hybrid Authentication Mode for IKE" which is adopted my more and more implementations right now (= far too late). Cisco is now pushing it because of the failure of their own "group password scheme" (of course they name it differently: "Mutual Group Authentication").

Man, why did they wait so long?

/graf0z.

Yeah these were my question for the most part.

Jpeg compression ruin the image a little.

It is not due to the algorithm but the computer ability to deal with decimal points. I wonder if the extra compression ruin the image further.

They alter the huffman code(jpeg compression algorithm) or a second compression algorithm

I wonder how it handle corrupt files or a slight corruption.

A jpeg when corrupted loose a color or shade what will happen to the new compression when corrupt.

and for those that have no clue how jpeg work
http://www.faqs.org/faqs/jpeg-faq/part1/

JPEG does not use Run-length encoding as its last compression step. Quote from the faq:"The JPEG spec defines two different "back end" modules for the final output of compressed data: either Huffman coding or arithmetic coding is allowed." http://www.faqs.org/faqs/jpeg-faq/part1/section-18 .html It goes on to say that arithmetic coding is ~10% smaller, but is patented, so don't use it. So what they are doing is removing the known chubby huffman coding and replacing it.

the Intellectual Property-protocol (IP)

Damn, I've been tricked again! Now when I use DHCP to get my IP address, it's forcing onto an Intellectual Property network???
*sigh* I'll just sit here and wait for the lawsuit.

In all seriousness, last time I knew, the IP in TCP/IP stood for Internet Protocol

A few months ago I was working on a project that required the use of a particular data compression method (arithmetic coding), because of its great efficiency on the type of data I was supposed to process (uncompressed output from various audio codecs, including experimental ones). IBM owns no less than 19 patents on that algorithm and its derivatives. Sure, the first 3 of them are expired by now, but none of the others were in the 500 list.

Data compression is one of the areas where pure software patents are commonplace and very annoying, which makes your choices very narrow when it comes to choosing a compression method for your projects. Check it out here.

Read Eric Raymond's "The Art of Unix Programming", available online here, especially Chapter 19 about good free software development practices. Most of the guidelines are directed towards contributors instead of project maintainers, but you will get a good overview of the "best practices". The rest of the book might be less interesting to you if you're a Windows guy, but it's still a nice read (ignore ESR's random political rants and self-righteous examples) and gives a good overview of "The Unix way" of doing software development.

Read Eric Raymond's "The Art of Unix Programming", available online here, especially Chapter 19 about good free software development practices. Most of the guidelines are directed towards contributors instead of project maintainers, but you will get a good overview of the "best practices". The rest of the book might be less interesting to you if you're a Windows guy, but it's still a nice read (ignore ESR's random political rants and self-righteous examples) and gives a good overview of "The Unix way" of doing software development.

i'm a bit surprised nobody pointed it out yet, but the good people from the IETF aleady worked how to store and represent dates for the rest of the time our universe will exist (and beyond):
http://www.faqs.org/rfcs/rfc2550.html

According to RFC 3022:

Traditional NAT can be viewed as providing a privacy mechanism as sessions are uni-directional from private hosts and the actual addresses of the private hosts are not visible to external hosts.

NAT devices, when combined with ALGs, can ensure that the datagrams
injected into Internet have no private addresses in headers or
payload. Applications that do not meet these requirements may be
dropped using firewall filters. For this reason, it is not uncommon
to find NAT, ALG and firewall functions co-exist to provide security
at the borders of a private network.

borked a derivative of the term "borken" which is a deliberate misspelling of "broken". Pre-dates the Bork Supreme Court nomination which some people have claimed was a root.

I rolled on the floor laughing at those stupid white men fearing that there would be power shortages due to the Y2K bug. Come on, what's Y2K having to do with the hydroelectrical plants? It's just turbines and "primitive" electric distribution systems.

Ah... glorious days. I laughed even more when I saw on the news that people started collecting food for their shelters... oh boy! Bring me my popcorn. X-D

On related news, check out RFC 2550 about the Y10K disaster that is looming above us.
...and here's Mike with the weather.

Don't worry, a solution to the Y10K problem has already been proposed - RFC 2550 covers it very extensively.

I've had decent luck with PPP over SSH. It's not the fastest (although I haven't done any tuning of my PPP config), but all the components needed are pre-installed on most modern 'nix boxes.

See http://www.faqs.org/docs/Linux-mini/ppp-ssh.html

c.

With edonkey network (as well as KaZaA and Gnutella) you can distribute small links to content without requiring either torrent hosts or trackers.

Tell me, has Gnutella become 9000% more efficient in the past year? (Ratio of overhead byte to file data) I haven't looked at it lately, but that's what it would need to become competitive with Bit Torrent.

Torrents suck. There is nothing good about torrents. They are huge, they require gobs of bandwidth and you can't distribute them without setting a server.

Lies. A largish torrent is 30kb. That's not huge. And you don't "need a server" anymore than you do with Kazaa or edonkey (which is to say, you do need a program capable of handling the service, something a modern bittorrent client does transparently) There are many dedicated edonkey servers out there, you know...

Torrents are excellent because the follow the Unix software-design philosophy about separation of functionality ("Do one thing, and do it well"). P2p file transfer and file searching are wholely different tasks, and should be cleanly separated as much as possible.

One useful benefit (amoung many) is that Bit Torrent is legal, while edonkey is often (and unpredictably) illegal... I can join a bittorrent for a free videogame and be 100% certain that 0% of my bandwidth is supporting traffic in handicam movies and child porn.

If the ed2k-style file search feature was actually better enough to be attractive, then it could be easily used in conjunction with bittorrent as an entirely separate application.

PS. ed2k links are fatally flawed. The hash algorithm they use is trivally vulnerable to poisoning: an attacker can easily corrupt everyone's downloads, and the network has no defense mechanism.

Sigh. What you wrote is essentially meaningless --- at least I can't see how to generalize the definition of a bit.

I'm pretty sure you are talking about what would be the great-grandparent to this message, and that's not me.

You are, I assume, referring to "fuzzy logic" here.

Not necessarily. Let's try this: A bit, fundamentally, is a statement of knowlegde of a binary proposition. A 1 means that you are fully confident it is true, a 0 means that you are fully confident it is false.

Is that the only definition of bit? Hell no! But what fundamental math concept only has one applicable definition? (Is it just me or is discrete even worse than continuous this way?) Certainly as I said it is useful. Fuzzy logic is one case, but not a very exciting one since it was shown to be equivalent to non-fuzzy logic; error correction is a much more relevant, albeit practical (i.e., not "mathematical" :-) ) one.

Obviously the idea of a fractional bit falls right out of this probabilistic definition; it's something you only have a probability for, not a certainty. But it can come up in other contexts too; there is a measure of entropy which naturally gives fractional bits. It is easy to create a parity scheme for data transmission that provides 1.5 bits of protection; a one-bit error is guaranteed to be detected but a two bit error has a 50-50 chance of going undetected. (Nothing like that is in use AFAIK, probabilistic detection was pure anathema to computer science until fairly recently, but one can be constructed.) Here, it is not that there is a .5 bit floating around, but the protection the algorithm and data would provide is neither 1 bit nor 2: 1.5.

Fractional bits are like QM superpositions; you're right in the sense that they can't be "observed" (for some suitable definition of "observed"), and thus in way they aren't "real", but without them a lot of math "stops working".

As for the way that other guy tried to use it, at this point I don't even remember, so I can't speak to whether he used it correctly. I was just trying to clarify my original point with solid examples and take a shot at explaining fractional bits. I'll also re-recommend going to the source on this one; a full understanding of encryption is something few people even can obtain and even fewer can dedicate the time, but for an experienced mathematician, the introductory terms and definitions are fairly easy and, at least in the computer domain, actually quite useful as thinking tools. I only wish I could point you at a free online source easily... well, let me see... well, this is a start, I guess, though it is so ugly in plaintext it is hard to read and didn't have what I was hoping for, but I'm not sure anything like that would be online anyhow... at any rate, the algorithms and crack techniques have passed beyond what any Mere Mortal could hope to understand or contribute to in any reasonable time period, but the basics are quite basic.

Myth 1 Debunked: "[A]s the name says, Wine Is Not a (CPU) Emulator."

Wine just provides the Windows API. This means that you will need an x86-compatible processor to run an x86 Windows application, for instance from Intel or AMD.

2.1. What is Wine and what is it supposed to do?
Wine is a program which allows the operation of DOS and MS Windows programs (Windows 3.x and Win32 executables) on UNIX operating systems such as Linux. It consists of a program loader, which loads and executes a Windows binary, and a set of libraries that implements Windows API calls using their UNIX or X11 equivalents. The libraries may also be used for porting Win32 code into native UNIX executables, often without many changes in the source.

1.1: What is Wine, and what is it supposed to do?
Wine is a program which allows the operation of DOS and MS Windows programs (Windows 3.x and Win32 executables) on UNIX. It consists of a program loader, which loads and executes a Windows binary, and a library that implements Windows API calls using their UNIX or X11 equivalents. The library may also be used for porting Win32 code into
native UNIX executables.

QOS? Why, just filter The evil Bit out.

Try searching google for "Intrusion detection system" for some of what you might be referring to.

Simply run everything over port 80, as suggested in RFC 3093, the Firewall Enhancement Protocol.

It's the one next to the Evil bit. RFC 3514.

WE (people) don't do anywhere near the damage to this planet than the planet does to itself!

So because Hitler killed millions, it makes it OK for me to kill 1 since it is not anywhere near the damage?

Damn. I ended my own argument.

The GUI, in the user sense, is an afterthought. You have to go to the command line to configure and/or adjust and/or install many things. Now, I don't really care a bit about this, but most users will want to avoid command line stuff. Lock out many users with this kind of esoterica, and you've made an error, IMHO. One of the places an OS gets strength from is a broad userbase in the sense of "not one demographic" (such as only technical types.) If Linux doesn't offer ease of use, then they'll go where they can get it - Windows, OS X. And we lose. Sure, some of you just chortle at the very thought, but I truly think you're being shortsighted when you do.

Your complaint is valid in the sense that there are many tasks that can't be done through the GUI, but only through the lower level (design-wise) command line interface. That's the result of being an incomplete system. This is very different from being the result of an ill-designed system.

For those of you who don't remember the evil bit, it's RFC 3514.

As far as things I'd like to see improved - at a job a while ago, I had to use an IBM mainframe (OS/390, I think), and while overall I found it pukeable, one thing I did really like was the fact that you could log on later and review the exit status of any of your jobs. (Which makes perfect sense for a batch-oriented system.) In Unix, if you don't immediately check $?, you've lost the exit status of your jobs. Shell history only captures what you entered, and only from the shell itself. As a system administrator, I'm often running things in the background, via screen, on multiple systems, from cron, etc., and it would be nice to be able to be able to check on everything that's run. There is auditing, but that's usually a real pain to set up.

I'm a little surprised that no one has mentioned (as far as I've noticed) ESR's The Art of Unix Programming, which has a section titled "Problems in the Design of Unix". From that book:

Unix files have no structure above byte level. File deletion is irrevocable. The Unix security model is arguably too primitive. Job control is botched. There are too many different kinds of names for things. Having a file system at all may have been the wrong choice.

As far as things I'd like to see improved - at a job a while ago, I had to use an IBM mainframe (OS/390, I think), and while overall I found it pukeable, one thing I did really like was the fact that you could log on later and review the exit status of any of your jobs. (Which makes perfect sense for a batch-oriented system.) In Unix, if you don't immediately check $?, you've lost the exit status of your jobs. Shell history only captures what you entered, and only from the shell itself. As a system administrator, I'm often running things in the background, via screen, on multiple systems, from cron, etc., and it would be nice to be able to be able to check on everything that's run. There is auditing, but that's usually a real pain to set up.

I'm a little surprised that no one has mentioned (as far as I've noticed) ESR's The Art of Unix Programming, which has a section titled "Problems in the Design of Unix". From that book:

Unix files have no structure above byte level. File deletion is irrevocable. The Unix security model is arguably too primitive. Job control is botched. There are too many different kinds of names for things. Having a file system at all may have been the wrong choice.

Oh yeah, and for a more formal statement of what I just said and an explanation of the Copenhagen interpretation of quantum mechanics (entirely unsatisfactory) and the many worlds hypothesis (nutty) and other joyously insane answers to the measurement problem, see the Measurement in QM FAQ.

I thought the same thing, but then I realised, they just filled in the BCC fields.

An example copied from the FAQ page ('r' is the server and 's' is the client):

R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
S: HELO LBL-UNIX.ARPA
R: 250 USC-ISI.ARPA
S: MAIL FROM:<mo@LBL-UNIX.ARPA>
R: 250 OK
S: RCPT TO:<Jones@USC-ISI.ARPA>
R: OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: .
R: 250 OK
S: QUIT
R: 221 USC-ISI.ARPA Service closing transmission channel

The Data command starts the RFC822 message that you usually associate with your email.

I thought the same thing, but then I realised, they just filled in the BCC fields.

An example copied from the FAQ page ('r' is the server and 's' is the client):

R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
S: HELO LBL-UNIX.ARPA
R: 250 USC-ISI.ARPA
S: MAIL FROM:<mo@LBL-UNIX.ARPA>
R: 250 OK
S: RCPT TO:<Jones@USC-ISI.ARPA>
R: OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: .
R: 250 OK
S: QUIT
R: 221 USC-ISI.ARPA Service closing transmission channel

The Data command starts the RFC822 message that you usually associate with your email.

When you see 'hungry', you quickly realize that you need to eat something (like corpses) and you learn which corpses to reject. But the problem I was facing occurs when you run out.

Aside from going deeper, I eventually figured out that #pray frequently saves you in those circumstances (poisoning, low health, etc), but doing that isn't apparent to a beginner. I was punished severely when praying for the first time while experimenting commands, which dissuaded me from that course later on (those first 70something games).

And yes, it's your own business whether you cheat in your own, single-player games. However, you'll enjoy the game much more if you learn to play it properly.

I agree. The savescumming was a response to the game difficulty. I will say that the lessons do get learned, but the penalty involved is not as harsh.

On the topic of cheating (since it seems to be the focus of this thread) ...

I just had a look at this FAQ and something bothers me a bit.

If one were to be strict in the definition of cheating here, any FAQ use (with/without spoilers) is essentially reducing the difficulty of the game by knowledge gained through external channels. Considering that there are a variety of unexpected uses for many items, a true non-cheater would never learn some of the aspects of gameplay so as to play the game properly.

My criticism of the FAQ is that they demonize game saving while at the same time provide advice for gameplay (a different form of cheating)

The game IS hard. I chose to cheat by discovering a way to save games (I wasn't aware that it had a name) while others cheat via FAQs and spoilers (I didn't look at a FAQ/spoilerlist prior to this thread). In that light: I see myself as not much of a cheater, among cheaters. Of course, this may be just a rationalization on my part...

I understand how saving can be seriously abused and that approach doesn't appeal to me (just once every four or so levels). However, any saving greatly reduces the amount of randomization I like about this game, which is leading me to the decision to stop using it.

Almost there with RFC3251 just need to implement it ;-)

There was time when TLD meant something. You knew a .com was a company, a .org was a non-profit,...

"ORG" exists as a parent to subdomains that do not clearly fall within the other top-level domains. This may include technical- support groups, professional societies, or similar organizations.

Packet prioritization does not work in the real world beyond the LAN because of the potential for abuse.

Wrong, in 3 ways. You can already modify your TCP and HTTP stacks to abuse the system for an unfair benefit, and yet most people don't.

If ISPs were known to obey packet priority settings, everyone (...) would set all their packets to maximum priority

If airlines were known to offer more comfortable "first class seating", everyone would use it, and enjoy more space at everyone else's expense.

Naturally, packet prioritization only works if the user somehow pays more for the better packets. (There are numerous ways to structure that pricing, some of them simplistic) This requirement is so obvious that advocates of priority levels usually don't bother to mention it.

I believe TCP/IP has always supported packet prioritization

Wrong. (Do not confuse the "Urgent" flag with something that network routers will treat specially- it is only for use of recieving applications)

Like gzip?

gzip file format definition

KFG

This has been a PSA brought to you by Ima Troll.

Take your adolescent whining elsewhere, please. You make forums an unpleasant place to be.

Please see the following links for further information.

http://www.faqs.org/rfcs/rfc1855.html
http://ars.userfriendly.org/cartoons/?id=20030324

The second link may be more within your grasp, as it's not 100% text. It seems people have problems with reading when there aren't any pictures.

From RFC 2821 SMTP description

6.1 Reliable Delivery and Replies by Email

When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage.

I have 10,000 monkeys with MFAs. They're working on a novel right now.

You seem to be using only 10,000 monkeys, while the IMPS protocol clearly calls for an infinite number.

Obviously, you are not conforming with RFC 2795. Please rectify this or you may become a pariah on /.

That might have been true before 2000, but the effort to calculate both algorithm in parallel ( not SMP, just passing the input bytes to each function ) is negligible with modern CPUs, both PC and embedded. The limiting bottlenecks are the network, hard drive and memory, not the CPU power required

gokeln wrote: "You do not get exponentially improved security"

When anyone uses the phrase "exponentially improved security", it triggers a link to Avoiding bogus encryption products: Snake Oil FAQ.

One of us is spreading FUD. It's not me.

Please see, for example, RFC 1036, which has a section all about expiry of Usenet messages. It provides for including an "Expires" header, but recommends against using it except where there's an obvious expiration date (e.g., for announcements, after the thing they announce has happened), with a local default expiration date being the default if nothing is specified in the message. Claiming that "local default expiration date" means "keep it forever" is like claiming that US copyright law should be extended forever to support the big media corps.

I've been using Usenet for more than a decade, and in my experience, no NNTP-server, whether in academia or commercially run, kept messages indefinitely. Local policies on message lifetimes I've encountered have ranged from around 1-4 weeks, with 2 being pretty typical.

Since this is both what the RFC provides for and what has actually happened since forever, claiming that someone is giving implicit permission to do more by posting in the first place is a very weak argument.

You'll note this does make use of CNAMEs, but that doesn't mean it's not "delegatable", it means it is.

According to the standard, the from field should have the email address the mail was sent from (in this case your uni addy).

No, that's "Sender". From RFC 2822:

The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message.

Apple should invent an e-book reader.

They already had one, years ago. It was called the Newton.

Back when I was working for ANS - err, UUNet - umm, WorldCom - I would download text files, convert them to Newton Book files, upload them to my trusty Newton 2100, and read away. I read The Hacker Crackdown while taking lunchtime walks, as well as a few RFCs.

The Newton's form factor would still be great for an ebook reader. There's still a small but rabid base of people still writing software for the Newton, including mp3 players, 802.11 support, and even a web server! Surely someone can be persuaded to come up with a modern book reader / creator package for the Newton.

The only problem with this is the pride of Steve Jobs. One of his first actions upon returning to the Apple helm was the killing of the entire Newton program, ostensibly as it was the baby of John Sculley, the man who had Jobs removed from Apple. Apple still has the rights to the name and the hardware, and the Inkwell software that's included with OS X supposedly came from the Newton handwriting recognition software, so I can't see a reason why this wouldn't be possible.

Then again, I'm a hopeless dreamer about seeing the best PDA platform in existance making a return to the market :)

... represents a potential Achilles' heel for our financial stability and physical security if the networks we are creating are not protected ...

... represents a potential Achilles' heel for our financial stability and physical security if the networks we are creating are not protected ...

Dude, the Saturn V Plans aren't lost, it's just incredibly pointless to try and build one at this point. It's an awfully tired myth at this point.

And it doesn't matter because you can launch a mars shot in two or three launches of a shuttle derived booster anyway.

And read the FAQ for yourself.

You can still use VoIP with that.

midcom-p2p.sf.net has an implementation called natcheck which might be handy. Note that you can even connect via TCP sometimes; Bryan Ford is writing a paper about that. See also draft-ford-midcom-p2p-03.txt, RFC3489 (STUN), and my site, alumnus.caltech.edu/~dank/peer-nat.html.