It did *say* it was the cheat code for Contra, so you don't have to think of it yourself:)
Personally, I remember Contra, but never heard of that cheat code. Oh well.
On an unrelated note -
The average American child plays videogames forty-nine minutes a day, but games are no longer the province of kids; 61 per cent of videogamers are eighteen or older, and more than a
quarter are over thirty-six. Videogames are no longer bounded by gender, either: players are
evenly divided between men and women.
I'm 31. I play computer games. I know lots of people who play computer and video games, young and old (like me.) And the vast majority are guys. There's no way in hell that the `players are evenly divided between men and women' unless you consider everybody who has started Solitaire at least once in the last decade as a `video game player'. The vast majority of the serious gamers I know are guys, at least 80%.
The problem, as it appears now, is that IBM uses partition type 165 for it's suspend-to-disk feature, and when the bios boots it looks for a suspend-to-disk partition to reload. When
it sees FreeBSD's huge partition the laptop freezes solid.
Ahh. Learn something new every day. I was half right though -- it was related to save-to-disk.
Does FreeBSD actually care if this partition is type 165 or not? If not, a simple fix would be to change it to something else. The question is this -- does FreeBSD actually care? I don't know, it would require some experimentation. Don't try it on your own system unless you have an easy way to change it back (it wouldn't be hard, of course.)
What was IBM thinking, anyways? Partition type 165 has been used by *BSD on PC's for years now. They really should fix this -- it should be simple, and may save some face.
FreeBSD has two ways that you can partition your disk -- a `compatible' way and a non compatible way.
The compatible method creates a standard partition table, and then creates all the FreeBSD slices within it.
The non-compatible method just creates the FreeBSD slices directly on the raw disk device. Works great with FreeBSD, but DOS and Windows don't know what's going on and will probably want to create a new partition table, which would be... bad.
The advantage of the non-compatible method is that you get a little more disk space, and you're not bowing to DOS's limitations:)
My guess is that the BIOS in the Thinkpad requires a valid partition table in the disk (probably for suspend to disk or something like that) or it'll freak out.
The fix would be simple -- just use the compatible partitioning system, which I guess is not the default. This is no big deal.
Of course, this is all conjecture, but I suspect I'm right.
RC5 might be reasonable for comparing x86 cpu to x86 cpu, but it's unreasonable for comparing x86 cpus to non x86 cpus. RC5 uses instructions that many processors don't have (but the x86 (and PPC for that matter) does have them) (few applications need these instructions, so it's rarely a problem) and so they have to use more complicated routines on those cpus. That's part of the reason that your Alpha cpu is so much slower at RC5 than your x86 ones.
Yes, and it's very unfortunate that ISPs don't fight things like this more rather than just caving in.
But you should also consider the ISP's position. Attacks like this often throw the entire ISP off the net, affecting *all* of their customers. Only the very largest ISPs can handle such attacks -- which waste large amounts of expensive connectivity.
It's *much* cheaper to just get rid of the offending site in most cases, and since most ISPs are businesses looking to make a profit, that's what they do. They'd like to fight it, only the largest ISPs can afford to fight it.
Ever wondered what happens when your IRC
chatter draws the attention of the public
servants at the FBI?
Obviously, it wasn't his IRC chatter that drew their attention. It was his poking around the crime scene, port scanning it and the like. Maybe the FBI *does* log all IRC traffic like people like to claim - but in this case, they were probably just watching everything that happened to the computer, perhaps hoping that the cracker would come back to it.
Am I the only one who thought it was odd that a hacked website was *still* up and in it's hacked state, even after the news made it onto several large news sites? Normally the first thing that people do in this sort of situation is take the site down, either by fixing the problem or pulling the power plug...
It seems that nobody remembers that tripwire was open source a long time ago...
## $Id: README,v 1.26 1994/08/26 08:22:48 gkim Exp $
##
## README for Tripwire
##
## Gene Kim & Gene Spafford
## The COAST Project
## Department of Computer Sciences
## Purdue University
##
## All files in the distribution of Tripwire are Copyright 1992, 1993, 1994
## by the Purdue Research Foundation of Purdue University. All rights
## reserved. Some individual files in this distribution may be covered
## by other copyrights, as noted in their embedded comments.
##
## Redistribution and use in source and binary forms are permitted
## provided that this entire copyright notice is duplicated in all such
## copies, and that any documentation, announcements, and other
## materials related to such distribution and use acknowledge that the
## software was developed at Purdue University, W. Lafayette, IN by
## Gene Kim and Eugene Spafford. No charge, other than an "at-cost"
## distribution fee, may be charged for copies, derivations, or
## distributions of this material without the express written consent
## of the copyright holder. Neither the name of the University nor the
## names of the authors may be used to endorse or promote products
## derived from this material without specific prior written
## permission. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY
## EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE
## IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR ANY PARTICULAR
## PURPOSE.
This README file serves as a quick-and-dirty primer on Tripwire.
A PostScript formatted paper that fully describes the design and
rationale is also included in the./docs directory. The design
document is also available as a technical report (TR-CSD-93/71). This
document will be referenced throughout the Tripwire distribution as
the Tripwire design document or the comprehensive Tripwire paper.
This README file contains information needed to build, test,
and run Tripwire. A table of contents follow:
0.0. If you were running an earlier version
1.0. Background
1.1. Goals of Tripwire
2.0. How to build Tripwire
2.1. Common Tripwire compilation problems
2.2. The siggen utility
3.0. Getting Tripwire up and running
3.1. Creating your tw.config file
3.2. A caveat about your Tripwire database
3.3. Testing Tripwire
3.4. Running Tripwire as an integrity checker
3.5. Keeping your database up-to-date
3.5.1. Running Tripwire in Interactive mode
3.5.2. Running Tripwire in Database Update mode
3.6. A quick-checking mode
4.0. Some Tripwire scaling hints for using Tripwire
in large sites
4.1. The tw.config grammar
4.2. How you might use these directives
5.0. Notes on signature routines
5.1. Performance vs. security
6.0. Signature routines
6.1. MD5
6.2. Snefru
6.3. CRC-32
6.4. CRC-16
6.5. MD4
6.6. MD2
6.7. SHA/SHS
6.8. Haval
6.9. null signature
7.0. Feedback and bug-reports
8.0. User contributions
9.0. Acknowledgements
...
As for Port 25 blocks... 95% of those who want to host an SMTP server are doing it for relays or their own spamming enterprises. The other 5% are doing it as a part of their technical consulting, and that's against the "for home and personal use only"
Bull.
If a spammer wanted to run a relay, he could easily block it off to everybody but himself. Most spammers don't even have the clue to run sendmail or it's eqivilent -- they just let their spam software do it all for them.
And lots of people run mail servers at home because they don't want to have to rely on the cable modem provider's mail server. Your little 95% and 5% breakdown doesn't leave much room for these people.
-- all of those nasty copy-protection schemes of the '80s, like bad floppy sectors
-- now, you don't get none of that
Actually, they're coming back. Many game CD's are now copy protected in various manners. This copy protection typically isn't as much of a PITA as it used to be, but they're still there, and they're still being defeated just as quickly as they were in the old days.
-- serial numbers (think windblows) keep honest people honest, while not affecting the dishonest
They're a PITA, but a minor one, for the honest. They're so easy to lose... (My advice: write the cd-key on the face of the cd itself. Then you won't lose it.)
And they do affect the dishonest somewhat, especially with multiplayer games such as Diablo ][.
On top of that it will run on
BeOS and MacOS, making it the most cross-platform mp3 player available.
Obviously somebody has never heard of mpg123 which runs on just about everything -- just about all of the *nix clones, Windows, OS/2. I don't see Mac or Beos (but a Beos port might be next to trivial.)
The problem with that idea your application
can do things like use seek() to jump around the file -- and this is completely legal, but it would give gzip/gunzip fits. If you allow seek() to
be broken or a no-op, then it might be a lot simpler to implement.
But yet things like this *have* been done, because we *do* have compressed filesystems -- but I'm not sure exactly how they work. Perhaps they compress based on blocks rather than on files.
To answer the original question about mounting a tar.gz file, well I think the Hurd can mount a.tar file. To mount a tar.gz file would be a good deal more difficult, because you need to be able to seek() around in there. Mounting a.zip file might be a little better, because you have a table
of contents at the end of the.zip file, so you can go directly to any file. The problem then becomes seek()ing within that file.
There's two AIM protocols out there - a text
protocol, and a binary protocol. The names of the protocols are TOC and oscar, but I keep forgetting which is which.
The AOL supplied clients use the binary protocol,
which isn't documented but gives more features
than the text protocol.
The text protocol is well documented, but lacks many features.
Clients like TiK and gaim use the text protocol
(but I believe that a version of gaim has been made to use the binary protocol as well.)
The Microsoft client I believe used the binary
protocol (they reverse-engineered it) and that's why AOL used the buffer overflow to detect it.
Actually, when you pump out all the gases inside a light bulb it burns out very quickly, because there's no gas pressure to help prevent the filament from evaporating.
Modern (well, they've been doing this for decades) bulbs keep an inert gas in there at a
fairly high pressure to keep the filament from
evaporating. I believe the `halogen' lights keep
a special gas at a lower pressure that lets it evaporate but then redeposits it back onto the filament.
The downside of having (an intert) gas in there is that it conducts heat away from the filament, reducing it's efficiency.
If there are bulbs still burning from 1910, it's probably because 1) they're not lit very often and 2) they don't get very hot. If you keep your light bulb filaments relatively cool, they don't burn out - but they also don't make much light. The hotter they get (to a point, of course), the more light they make, the higher the light/heat ratio, and the `whiter' the light, all good things when you're designing a light bulb.
Nobody seems to have mentioned it yet, but Windows Media Player files can (and are) be made to to go to a web site during, before of after the movie places. This has all the same security implications that the Word/Excel/whatever problem has, except that it's typically obvious when it happens.
I remember reading about the idea of a car powered by liquid nitrogen perhaps twenty years ago.
The idea was that it would be best `in the city' where you were always stopping and starting. When stopped, there was no engine to run, so no energy wasted there. That and with no emissions (certainly nitrogen gas isn't a problem) it didn't contribute to the pollution problem of the city.
Of course, the thing that people don't get with cars like this and with electric cars is this - sure, they don't create pollution -- but somewhere
pollution IS being created. Coal or something else is being burned
to charge your batteries or to liquify nitrogen from the air. The only way there's no pollution is if it's being powered by something else, like
nuclear, geothermal, solar or hydroelectric power. Great ideas, but not that commonly used yet.
Another problem with a car powered by liquid nitrogen - while it wouldn't be hard to rig an A/C unit out of this (and it would be next to free, not reducing your mileage at all), if you wanted a heater you'd have to burn gas for it, just like you do in an electric car.
Also, I imagine that using energy to create liquid nitrogen from the atmosphere and then letting it expand and harnessing that energy is going to be a good deal less efficient than just using that energy directly to run the car. Exactly how much less efficient I do not know (again, electric cars have the same problem. But generators and motors are very efficient, so the loss isn't much, unless the batteries lose a lot.)
And last, keeping it cold is a problem. And I'm not sure if you could carry enough liquid nitrogen to get much range, and you'd lose range every night your car is parked. Exactly how much depends on how well insulated the nitrogen storage is.
On a related note, how many really good single player games come out for the PC? Diablo 1 and 2 are the only ones that I can think of.
Lots. Lots and lots and lots of really good single player games come out for the PC. A large number of them also have multi-player modes, but there is no shortage of good single player games out there. Ones I've played recently include Diablo 2, Vampire, Homeworld, Half Life, System Shock 2, Freespace 2, Age of Empires 2, etc. Of course, I've probably forgotten some and I certainly don't have time to play everything. But there's no shortage of good single player games out there.
huh? It doesn't matter what terminal type somebody has.
The problem is that depending on the shell the ^M's will be seen as additional options. `cat >> file1 ^M' isn't going to work, but `cat >> file1 ; ^M' will give an error but *will* work.
Basically it was clever to add them for whomever created the instructions.
The only thing they memorized was how to cut and paste. See how all the lines ended in ; ? <p> That was probably done by whomever wrote up the root kit because these people would paste everything, including the MS-DOS ^M's that you see causing errors in the transcript. People who know what they're doing don't do that.
Slashdot Mirror
Personally, I remember Contra, but never heard of that cheat code. Oh well.
On an unrelated note -
I'm 31. I play computer games. I know lots of people who play computer and video games, young and old (like me.) And the vast majority are guys. There's no way in hell that the `players are evenly divided between men and women' unless you consider everybody who has started Solitaire at least once in the last decade as a `video game player'. The vast majority of the serious gamers I know are guys, at least 80%.Does FreeBSD actually care if this partition is type 165 or not? If not, a simple fix would be to change it to something else. The question is this -- does FreeBSD actually care? I don't know, it would require some experimentation. Don't try it on your own system unless you have an easy way to change it back (it wouldn't be hard, of course.)
What was IBM thinking, anyways? Partition type 165 has been used by *BSD on PC's for years now. They really should fix this -- it should be simple, and may save some face.
The compatible method creates a standard partition table, and then creates all the FreeBSD slices within it.
The non-compatible method just creates the FreeBSD slices directly on the raw disk device. Works great with FreeBSD, but DOS and Windows don't know what's going on and will probably want to create a new partition table, which would be ... bad.
The advantage of the non-compatible method is that you get a little more disk space, and you're not bowing to DOS's limitations :)
My guess is that the BIOS in the Thinkpad requires a valid partition table in the disk (probably for suspend to disk or something like that) or it'll freak out.
The fix would be simple -- just use the compatible partitioning system, which I guess is not the default. This is no big deal.
Of course, this is all conjecture, but I suspect I'm right.
I guess that's the PCL at the University of Texas at Austin.
I spent way too much time there, though I seem to have spent most of my time in the UGL or in the Physics-Math Library rather than the PCL.
RC5 might be reasonable for comparing x86 cpu to x86 cpu, but it's unreasonable for comparing x86 cpus to non x86 cpus. RC5 uses instructions that many processors don't have (but the x86 (and PPC for that matter) does have them) (few applications need these instructions, so it's rarely a problem) and so they have to use more complicated routines on those cpus. That's part of the reason that your Alpha cpu is so much slower at RC5 than your x86 ones.
But you should also consider the ISP's position. Attacks like this often throw the entire ISP off the net, affecting *all* of their customers. Only the very largest ISPs can handle such attacks -- which waste large amounts of expensive connectivity.
It's *much* cheaper to just get rid of the offending site in most cases, and since most ISPs are businesses looking to make a profit, that's what they do. They'd like to fight it, only the largest ISPs can afford to fight it.
They've been saying it for years now. It's still true ...
Am I the only one who thought it was odd that a hacked website was *still* up and in it's hacked state, even after the news made it onto several large news sites? Normally the first thing that people do in this sort of situation is take the site down, either by fixing the problem or pulling the power plug ...
It seems that nobody remembers that tripwire was open source a long time ago ...
./docs directory. The design
## $Id: README,v 1.26 1994/08/26 08:22:48 gkim Exp $
##
## README for Tripwire
##
## Gene Kim & Gene Spafford
## The COAST Project
## Department of Computer Sciences
## Purdue University
##
## All files in the distribution of Tripwire are Copyright 1992, 1993, 1994
## by the Purdue Research Foundation of Purdue University. All rights
## reserved. Some individual files in this distribution may be covered
## by other copyrights, as noted in their embedded comments.
##
## Redistribution and use in source and binary forms are permitted
## provided that this entire copyright notice is duplicated in all such
## copies, and that any documentation, announcements, and other
## materials related to such distribution and use acknowledge that the
## software was developed at Purdue University, W. Lafayette, IN by
## Gene Kim and Eugene Spafford. No charge, other than an "at-cost"
## distribution fee, may be charged for copies, derivations, or
## distributions of this material without the express written consent
## of the copyright holder. Neither the name of the University nor the
## names of the authors may be used to endorse or promote products
## derived from this material without specific prior written
## permission. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY
## EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE
## IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR ANY PARTICULAR
## PURPOSE.
This README file serves as a quick-and-dirty primer on Tripwire.
A PostScript formatted paper that fully describes the design and
rationale is also included in the
document is also available as a technical report (TR-CSD-93/71). This
document will be referenced throughout the Tripwire distribution as
the Tripwire design document or the comprehensive Tripwire paper.
This README file contains information needed to build, test,
and run Tripwire. A table of contents follow:
0.0. If you were running an earlier version
1.0. Background
1.1. Goals of Tripwire
2.0. How to build Tripwire
2.1. Common Tripwire compilation problems
2.2. The siggen utility
3.0. Getting Tripwire up and running
3.1. Creating your tw.config file
3.2. A caveat about your Tripwire database
3.3. Testing Tripwire
3.4. Running Tripwire as an integrity checker
3.5. Keeping your database up-to-date
3.5.1. Running Tripwire in Interactive mode
3.5.2. Running Tripwire in Database Update mode
3.6. A quick-checking mode
4.0. Some Tripwire scaling hints for using Tripwire
in large sites
4.1. The tw.config grammar
4.2. How you might use these directives
5.0. Notes on signature routines
5.1. Performance vs. security
6.0. Signature routines
6.1. MD5
6.2. Snefru
6.3. CRC-32
6.4. CRC-16
6.5. MD4
6.6. MD2
6.7. SHA/SHS
6.8. Haval
6.9. null signature
7.0. Feedback and bug-reports
8.0. User contributions
9.0. Acknowledgements
...
I'm glad to see it's back (sort of, anyways.)
Bull.
If a spammer wanted to run a relay, he could easily block it off to everybody but himself. Most spammers don't even have the clue to run sendmail or it's eqivilent -- they just let their spam software do it all for them.
And lots of people run mail servers at home because they don't want to have to rely on the cable modem provider's mail server. Your little 95% and 5% breakdown doesn't leave much room for these people.
-- now, you don't get none of that
Actually, they're coming back. Many game CD's are now copy protected in various manners. This copy protection typically isn't as much of a PITA as it used to be, but they're still there, and they're still being defeated just as quickly as they were in the old days.
-- serial numbers (think windblows) keep honest people honest, while not affecting the dishonest
They're a PITA, but a minor one, for the honest. They're so easy to lose ... (My advice: write the cd-key on the face of the cd itself. Then you won't lose it.)
And they do affect the dishonest somewhat, especially with multiplayer games such as Diablo ][.
But yet things like this *have* been done, because we *do* have compressed filesystems -- but I'm not sure exactly how they work. Perhaps they compress based on blocks rather than on files.
To answer the original question about mounting a tar.gz file, well I think the Hurd can mount a .tar file. To mount a tar.gz file would be a good deal more difficult, because you need to be able to seek() around in there. Mounting a .zip file might be a little better, because you have a table
of contents at the end of the .zip file, so you can go directly to any file. The problem then becomes seek()ing within that file.
The AOL supplied clients use the binary protocol, which isn't documented but gives more features than the text protocol.
The text protocol is well documented, but lacks many features.
Clients like TiK and gaim use the text protocol (but I believe that a version of gaim has been made to use the binary protocol as well.)
The Microsoft client I believe used the binary protocol (they reverse-engineered it) and that's why AOL used the buffer overflow to detect it.
Modern (well, they've been doing this for decades) bulbs keep an inert gas in there at a fairly high pressure to keep the filament from evaporating. I believe the `halogen' lights keep a special gas at a lower pressure that lets it evaporate but then redeposits it back onto the filament.
The downside of having (an intert) gas in there is that it conducts heat away from the filament, reducing it's efficiency.
If there are bulbs still burning from 1910, it's probably because 1) they're not lit very often and 2) they don't get very hot. If you keep your light bulb filaments relatively cool, they don't burn out - but they also don't make much light. The hotter they get (to a point, of course), the more light they make, the higher the light/heat ratio, and the `whiter' the light, all good things when you're designing a light bulb.
Nobody seems to have mentioned it yet, but Windows Media Player files can (and are) be made to to go to a web site during, before of after the movie places. This has all the same security implications that the Word/Excel/whatever problem has, except that it's typically obvious when it happens.
The idea was that it would be best `in the city' where you were always stopping and starting. When stopped, there was no engine to run, so no energy wasted there. That and with no emissions (certainly nitrogen gas isn't a problem) it didn't contribute to the pollution problem of the city.
Of course, the thing that people don't get with cars like this and with electric cars is this - sure, they don't create pollution -- but somewhere pollution IS being created. Coal or something else is being burned to charge your batteries or to liquify nitrogen from the air. The only way there's no pollution is if it's being powered by something else, like nuclear, geothermal, solar or hydroelectric power. Great ideas, but not that commonly used yet.
Another problem with a car powered by liquid nitrogen - while it wouldn't be hard to rig an A/C unit out of this (and it would be next to free, not reducing your mileage at all), if you wanted a heater you'd have to burn gas for it, just like you do in an electric car.
Also, I imagine that using energy to create liquid nitrogen from the atmosphere and then letting it expand and harnessing that energy is going to be a good deal less efficient than just using that energy directly to run the car. Exactly how much less efficient I do not know (again, electric cars have the same problem. But generators and motors are very efficient, so the loss isn't much, unless the batteries lose a lot.)
And last, keeping it cold is a problem. And I'm not sure if you could carry enough liquid nitrogen to get much range, and you'd lose range every night your car is parked. Exactly how much depends on how well insulated the nitrogen storage is.
There's still great RTS games being made today. Myth, Myth II were great. I'm enjoying Dark Reign II right now, even though it is `more of the same'.
FreeSpace 2 was an awesome space sim, with a story as good as Tie Fighter (which is still one of the best games ever, don't get me wrong.)
I've heard great things about the adventure game `The Longest Day', but haven't played it -- mostly because it's not available in the US yet.
Flight sims I never cared much for, but I seem to see lots of them on the store shelves even today.
Seemed like an honest enough mistake to me. Certainly doesn't qualify as `screwing' Debian.
Lots. Lots and lots and lots of really good single player games come out for the PC. A large number of them also have multi-player modes, but there is no shortage of good single player games out there. Ones I've played recently include Diablo 2, Vampire, Homeworld, Half Life, System Shock 2, Freespace 2, Age of Empires 2, etc. Of course, I've probably forgotten some and I certainly don't have time to play everything. But there's no shortage of good single player games out there.
PC gaming isn't dead. It's alive and well.
The problem is that depending on the shell the ^M's will be seen as additional options. `cat >> file1 ^M' isn't going to work, but `cat >> file1 ; ^M' will give an error but *will* work.
Basically it was clever to add them for whomever created the instructions.
The only thing they memorized was how to cut and paste. See how all the lines ended in ; ?
<p>
That was probably done by whomever wrote up the root kit because these people would paste everything, including the MS-DOS ^M's that you
see causing errors in the transcript. People
who know what they're doing don't do that.