Yeah, Sony Trinitons are pretty indestuctable, especially the mid-80s XBR (semi-pro) line.
We have a 27" XBR that was purchased in December 1985, with all kinds of inputs, including digital RGB, and its still just fine.
So, when I needed two new TVs this Xmas, guess what I bought? The 36" and 21" have joined their older sibling and all is well, and I know I'll never have to have them repaired.
As for plasma/LCD, why? Just because they are available doesn't mean that your CRT TVs are obsolete. I love to buy at the back side of the tech curve. Home computers are ~1Ghz, CRT monitors, 80G drives, 32x CD-ROM instead of 52x, etc. I've got 1 and 2 year old Palm/Handsprings and they work just fine.
I love to allow other people to pay the development and launch costs of new products.
Funny, we did this work almost a year ago, and someone finally notices:-(
Yes, this is a very small part of the total theorectical key space.
But its exactly the part of the space that is most "interesting"; this is the part that will most likely be searched by an attacker AND the part that is most likely to have a real, user-selected password.
The original goal (years ago) was to allow us to verify that our users weren't using passwords that would be likely to be found by an attacker.
Yes, passwords are *supposed* to be stored in shadow files that are not accessible, except by root, but in practice, it is often discovered out in the Real World, especially at larger multi-vendor sites, that user password hashes are copied between machines, stored in databases, and in general available to an attacker who does not yet have root.
These are the same sites that often can't or haven't converted to md5() hashes, as they have older legacy OSes that don't do md5(). Note that even though Sun "supports" md5() hashes, they don't support them everywhere and it certainly isn't seamless. Don't get me started about AIX. Linux and the *BSD folks are way ahead of most of the commercial UNIX variants.
As for the scalability, read the whole paper. We used the largest single machine at SDSC, but its rather dated in terms of crypt() performance. A distributed.net-style project using typical home machines would win, IF you could get a thousand or so people to cooperate.
The Terabytes of storage in a single filesystem didn't hurt in the sort/merge phases either.
I am talking about GCOS 3, and GCOS 8, which ran on the 6000 and DPS-8 line (36-bits mainframes). If you are talking about GCOS-6, which ran on the Level-6 minicomputer line (18 bits! Wheee!!!), then I agree absolutely. Honeywell began to call all their OSes GCOS at some point (except CP6 and Multics, which they were trying to kill off!) some flavor of GCOS. Some branding and "we're portable just like UNIX!" play, I guess.
GCOS-6 looked so much like UNIX that it was amazing. If that's what you're talking about then I agree completely with you.
GCOS 3 and 8 looked like something from the dark ages (and they were).
As for GCOS 3 and 8, I'm quite sure of my facts. I was a GCOS (3) programmer, a GCOS 8 programmer, and a Multics programmer when I worked at Honeywell during that period. By programmer, I mean that I worked in GCOS Central Systems, the people who wrote, debugged and maintained those operating systems; for Multics I was a user, project admin and worked next door to the Multics developers in Phoenix. I also wrote PL/1 code for Multics, but not the central system. I also wrote code for the Level-6's in Phoenix to control the mainframe factory, but I didn't write any OS code, just applications.
Now, I suspect that we don't really disagree, we just have some different opinions about what "like UNIX" means, or we're talking about completely different systems. For me, UNIX means "has pipes, and every command is just a program". GCOS (3,8) TSS had no pipes, the commands were compiled into the TSS subsystem. In general, if you wanted to run a program that wasn't compiled into TSS, you had to use the "RUN" command. Search paths may have been added later, but I never saw them.
The syntax of the built in commands was rather like UNIX in lots of ways, but the command argument syntax was really all over the map.
If you (or other GCOS people) would like to discuss this directly, contact me.
Re:Multics had several parents, of which GCOS was
on
SCO's Plan Examined
·
· Score: 1
Actually, not. GECOS (General Electric Comprehensive Operating System), which became just GCOS when GE's mainframe business was sold to Honeywell, has and had nothing to do with Multics OR UNIX.
GCOS was a batch operating system that had a "time sharing subsystem" (TSS) which was a batch job itself, that just happened to own and talk to all the TTY (and later VT) devices attached to the front-end processors.
I worked on GCOS from 1973 until 1983, Multics from 1975 until 1983, and my first UNIX box was a PDP-11/70 running v6. I've got boxes of manuals in the garage if anyone wants to see the stuff.
GCOS timesharing commands looked more like what we know think of as MS-DOS, or TOPS-10.
Everquest, Star Wars Galaxies and Planetside are games from Sony Online Entertainment (a part of Sony of America, along with Sony Music, Sony Pictures) games. All (Sony first party) Playstation games (in the US) are Sony Computer Entertainment America (SCEA) which is part of SCE International.
What is now SOE was originally part of SCEA, but it was spun out into its own company, then purchased by Sony of America. Go figure.
The SOE and one of the SCEA offices are about a mile apart, and some former SCEA people are at SOE, but other than that, they have nothing in common.
The point of this is that experiences with EverCrack, et.al. will not be the same as FF XI, even taking the PC vs PS2 differences into account. SOE has servers all over the place (esp in the US), but FF XI will likely be hosted on servers in JP for all players worldwide. So check those ping times...
The product that Boeing has announced was acutally developed by Viasat in Carlsbad CA. I strongly suspect that Boeing is only the launch customer for this service.
This problem (queries that are attempting to look up IP addresses as if they were domain names) is quite simple.
It is broken software.
Specifically, it is software that has been ported from places where the resolver libraries had the (sometimes undocumented, but often depended on) feature of immediately returning when asked to resolve an IP address as a name.
In other words, lots of UNIX resolver libraries are happy to accept strings contining dotted-quad IP addresses. But the resolver lib is smart enough to just return the numeric IP address just as if you had resolved a name to get that address.
Lots of UNIX software expects that feature.
But if you then take that application to an OS (such as some Windows versions) where the resolver libraries don't have that "feature", they pass the string containing the IP address into the DNS system, leading to IP addresses appearing at the root nameservers.
The 30-minute timeframe (to the first intrusion on a default install) is not a bad guess. My logs show that many machines in my net are probed on average once every 15-180 minutes.
If the machines were default installs, they would have fallen. I'm seeing all the usual (for this week) stuff: SSH, apache, NIMBDA/Code.Red, FTP, etc.
Add about 15 minutes for installing a sniffer+hub in parallel instead of the single-host honeypot here, and 45-60 minutes of setup would get you a few hours of fun and amusement.
I think that the nost interesting part of this particular honeypot was the single honeypot system, instead of the victim + sniffer that I've used and almost always seen used.
Hmmm, I thought it was a rather old variant of Red Hat. We're basing that on the kernel and RPM versions.
We're running a production DNS server for our main domain on our PS2. There's also a baby web server. "The Effect" will probably knock it over, so please be gentle with it.
Why the DNS server? Because I bet someone they couldn't get it all running in less than 2 hours. I lost:-)
We have a computational chemist who is really contemplating a Beowulf cluster of PS2s, if he can get to the floating point on the graphics chips. The only drawback is the limited (32MB) of RAM. But for *small*-memory, FLOP-intensive jobs it might be cost-effective.
Well, since I'm the person who suggested an external review to the FBI, about a week before the hearing, I guess I should comment.
Also, since the FBI gave SDSC/PICS and my name as one of the groups being approached...
I can tell you that the group of people we have already approached (and have agreed in principle to participate) will be quite acceptable to you.
We have no interest in performing a "Clipper"-style review. No clearances, no secrecy, and no restrictions on anything we choose to publish are going to be requirements, or we won't play. And that would certainly send an interesting message.
Getting the source code, or at least doing a full reverse-engineer of Carnivore is the best of all possible worlds. But doing the reverse-engineer would be more difficult without doing the analysis of the existing product.
Since the FBI has repeatedly insisted that they only install Carnivore when the ISP can't give them what they need, they should have no objections to an open-source application that even an idiot-ISP could download, compile and install.
Don't trust me, and don't trust any panel of experts, but anything that *we* are involved in will provide enough information for a *qualified* person to do their own analysis.
Slashdot Mirror
Note that there have even been inter-operability studies with "the other" next-gen TCP stacks.
Yeah, Sony Trinitons are pretty indestuctable, especially the mid-80s XBR (semi-pro) line.
We have a 27" XBR that was purchased in December 1985, with all kinds of inputs, including digital RGB, and its still just fine.
So, when I needed two new TVs this Xmas, guess what I bought? The 36" and 21" have joined their older sibling and all is well, and I know I'll never have to have them repaired.
As for plasma/LCD, why? Just because they are available doesn't mean that your CRT TVs are obsolete. I love to buy at the back side of the tech curve. Home computers are ~1Ghz, CRT monitors, 80G drives, 32x CD-ROM instead of 52x, etc. I've got 1 and 2 year old Palm/Handsprings and they work just fine.
I love to allow other people to pay the development and launch costs of new products.
Funny, we did this work almost a year ago, and someone finally notices :-(
:-)
Yes, this is a very small part of the total theorectical key space.
But its exactly the part of the space that is most "interesting"; this is the part that will most likely be searched by an attacker AND the part that is most likely to have a real, user-selected password.
The original goal (years ago) was to allow us to verify that our users weren't using passwords that would be likely to be found by an attacker.
Yes, passwords are *supposed* to be stored in shadow files that are not accessible, except by root, but in practice, it is often discovered out in the Real World, especially at larger multi-vendor sites, that user password hashes are copied between machines, stored in databases, and in general available to an attacker who does not yet have root.
These are the same sites that often can't or haven't converted to md5() hashes, as they have older legacy OSes that don't do md5(). Note that even though Sun "supports" md5() hashes, they don't support them everywhere and it certainly isn't seamless. Don't get me started about AIX. Linux and the *BSD folks are way ahead of most of the commercial UNIX variants.
As for the scalability, read the whole paper. We used the largest single machine at SDSC, but its rather dated in terms of crypt() performance. A distributed.net-style project using typical home machines would win, IF you could get a thousand or so people to cooperate.
The Terabytes of storage in a single filesystem didn't hurt in the sort/merge phases either.
Personally, I'm a Kerberos fan
(Aha! I think I see what happened!)
I am talking about GCOS 3, and GCOS 8, which ran on the 6000 and DPS-8 line (36-bits mainframes). If you are talking about GCOS-6, which ran on the Level-6 minicomputer line (18 bits! Wheee!!!), then I agree absolutely. Honeywell began to call all their OSes GCOS at some point (except CP6 and Multics, which they were trying to kill off!) some flavor of GCOS. Some branding and "we're portable just like UNIX!" play, I guess.
GCOS-6 looked so much like UNIX that it was amazing. If that's what you're talking about then I agree completely with you.
GCOS 3 and 8 looked like something from the dark ages (and they were).
As for GCOS 3 and 8, I'm quite sure of my facts. I was a GCOS (3) programmer, a GCOS 8 programmer, and a Multics programmer when I worked at Honeywell during that period. By programmer, I mean that I worked in GCOS Central Systems, the people who wrote, debugged and maintained those operating systems; for Multics I was a user, project admin and worked next door to the Multics developers in Phoenix. I also wrote PL/1 code for Multics, but not the central system. I also wrote code for the Level-6's in Phoenix to control the mainframe factory, but I didn't write any OS code, just applications.
Now, I suspect that we don't really disagree, we just have some different opinions about what "like UNIX" means, or we're talking about completely different systems. For me, UNIX means "has pipes, and every command is just a program". GCOS (3,8) TSS had no pipes, the commands were compiled into the TSS subsystem. In general, if you wanted to run a program that wasn't compiled into TSS, you had to use the "RUN" command. Search paths may have been added later, but I never saw them.
The syntax of the built in commands was rather like UNIX in lots of ways, but the command argument syntax was really all over the map.
If you (or other GCOS people) would like to discuss this directly, contact me.
Actually, not. GECOS (General Electric Comprehensive Operating System), which became just GCOS when GE's mainframe business was sold to Honeywell, has and had nothing to do with Multics OR UNIX.
GCOS was a batch operating system that had a "time sharing subsystem" (TSS) which was a batch job itself, that just happened to own and talk to all the TTY (and later VT) devices attached to the front-end processors.
I worked on GCOS from 1973 until 1983, Multics from 1975 until 1983, and my first UNIX box was a PDP-11/70 running v6. I've got boxes of manuals in the garage if anyone wants to see the stuff.
GCOS timesharing commands looked more like what we know think of as MS-DOS, or TOPS-10.
Everquest, Star Wars Galaxies and Planetside are games from Sony Online Entertainment (a part of Sony of America, along with Sony Music, Sony Pictures) games. All (Sony first party) Playstation games (in the US) are Sony Computer Entertainment America (SCEA) which is part of SCE International.
What is now SOE was originally part of SCEA, but it was spun out into its own company, then purchased by Sony of America. Go figure.
The SOE and one of the SCEA offices are about a mile apart, and some former SCEA people are at SOE, but other than that, they have nothing in common.
The point of this is that experiences with EverCrack, et.al. will not be the same as FF XI, even taking the PC vs PS2 differences into account. SOE has servers all over the place (esp in the US), but FF XI will likely be hosted on servers in JP for all players worldwide. So check those ping times...
I wonder if any of the founders were ex-NRO?
The product that Boeing has announced was acutally developed by
Viasat in Carlsbad CA. I strongly suspect that Boeing is only the launch customer for this service.
This problem (queries that are attempting to look up IP addresses as if they were domain names) is quite simple.
It is broken software.
Specifically, it is software that has been ported from places where the resolver libraries had the (sometimes undocumented, but often depended on) feature of immediately returning when asked to resolve an IP address as a name.
In other words, lots of UNIX resolver libraries are happy to accept strings contining dotted-quad IP addresses. But the resolver lib is smart enough to just return the numeric IP address just as if you had resolved a name to get that address.
Lots of UNIX software expects that feature.
But if you then take that application to an OS (such as some Windows versions) where the resolver libraries don't have that "feature", they pass the string containing the IP address into the DNS system, leading to IP addresses appearing at the root nameservers.
reviews more reviews, and even more reviews.
Don't forget the movie reviews.
Looks like a real person who happens to write a lot of reviews. Some people review books, others post to slashdot...
Sorry, I was just finishing writing final exams and grading student papers when I wrote that note. Brain was tapioca...
The code is mucho less hypeful.
BEEP is the core of the syslog over TCP (syslog-reliable, AKA RFC 3195). Since Rose was one of the authors, no surprise there.
:-)
We've been writing a new syslog daemon that supports RFC 3195 (among others) and we're just getting to the BEEP stuff.
Its not pretty, but the flexibility looks interesting. Ask us about suck-factor in about a month, we should have some opinions by then
The 30-minute timeframe (to the first intrusion on a default install) is not a bad guess. My logs show that many machines in my net are probed on average once every 15-180 minutes.
If the machines were default installs, they would have fallen. I'm seeing all the usual (for this week) stuff: SSH, apache, NIMBDA/Code.Red, FTP, etc.
Add about 15 minutes for installing a sniffer+hub in parallel instead of the single-host honeypot here, and 45-60 minutes of setup would get you a few hours of fun and amusement.
I think that the nost interesting part of this particular honeypot was the single honeypot system, instead of the victim + sniffer that I've used and almost always seen used.
Hmmm, I thought it was a rather old variant of Red Hat. We're basing that on the kernel and RPM versions.
:-)
We're running a production DNS server for our main domain on our PS2. There's also a baby web server. "The Effect" will probably knock it over, so please be gentle with it.
Why the DNS server? Because I bet someone they couldn't get it all running in less than 2 hours. I lost
We have a computational chemist who is really contemplating a Beowulf cluster of PS2s, if he can get to the floating point on the graphics chips. The only drawback is the limited (32MB) of RAM. But for *small*-memory, FLOP-intensive jobs it might be cost-effective.
*ALL* biometrics authentication flaws boil down to one issue:
They are re-usable passwords that can NEVER be changed.
I could argue that in many implementations they are actually plaintext passwords, but that's not the point.
Think about all the work we've done on authentication systems over the last 30 years.
If PHBs didn't think biometrics were "cool", these ideas would have gone away a long time ago. They are flawed in so many ways.
Also, since the FBI gave SDSC/PICS and my name as one of the groups being approached...
I can tell you that the group of people we have already approached (and have agreed in principle to participate) will be quite acceptable to you.
We have no interest in performing a "Clipper"-style review. No clearances, no secrecy, and no restrictions on anything we choose to publish are going to be requirements, or we won't play. And that would certainly send an interesting message.
Getting the source code, or at least doing a full reverse-engineer of Carnivore is the best of all possible worlds. But doing the reverse-engineer would be more difficult without doing the analysis of the existing product.
Since the FBI has repeatedly insisted that they only install Carnivore when the ISP can't give them what they need, they should have no objections to an open-source application that even an idiot-ISP could download, compile and install.
Don't trust me, and don't trust any panel of experts, but anything that *we* are involved in will provide enough information for a *qualified* person to do their own analysis.