> 1. No way to rename files without losing revision info. > 2. Ditto for moving files.
Move and rename are the same operation under any non-stupid operating system (such as UNIX and workalikes).
These are difficult with CVS, but not impossible. Here's how:
1. Make sure EVERYBODY has released the directories you're renaming to/from (unless they like surprises) 2. Log in to the CVS server 3. Rename the,v files in the repository as you see fit 4. Checkout $CVSROOT/CVSROOT 5. Make the rename/etc changes in your modules, etc files 6. Check in $CVROOT/CVSROOT 7. Check out the tree you want to work on 8. ??? 9. Profit!
(I admit, step one is difficult with a large number of developers. Good thing we laid a bunch off.)
> 3. Can't handle symlinks.
True, but you don't need 'em 99.9% of the time. Just have your Makefiles create them:
The quotes are important if you have stupid people in your organization who think spaces belong in filenames. (And why does that only EVER happen with VB files? Gee, I wonder)
GBM would be relatively easy to "undo" with access to an appropriate lab. GBM ink is soaked into the paper; laser printing/photocopy ink is melted onto it.
It might be as simple as finding something which will react with toner to make it fluoresce under UV.
Unless, of course, you were running UNIX boxes, in which case trying to log in as root was pretty stupid anyhow. Well, unless you had really custom kernels. But that seem like an enormous waste of effort.
FWIW, I'm 99.99% that's from COTK. I didn't read much Clancy in those days (still don't, actually), but I remember that ploy and time frame clearly. I'm pretty damned sure I was reading COTK at the time. The one about the soviet tank commander, right?
> Apparently it's absolutely gutless unless you wind > it up enough for the turbo to kick in
Argh, that's unfortunate. I wonder if the WRC has the same motor?
On the other hand, I wonder how hard it would be to modify the WRX with the "VTEC" (quotes important) technology in the new Honda VFR 800 motorbike. It keeps half the exhaust valves closed 8000 rpm, allowing much more bottom end grunt than it would have other.
Probably cheaper to buy a new motor, though.
Still, depending on the turbo characteristics, that might okay. I ride a 250cc motorbike as my daily driver, and it is totally and completely limp below 8,000 RPM. Fortunately, after the first 8 grand there are another 6 to play with, and I'm quite good with the gear box.
I live about 5 miles from the Kingston Pen, and I can tell you that, without a shadow of a doubt, that nobody who has spent any time there will ever be reformed. This goes double for the guards -- the only difference between the guards and the inmates is what side of the bars they're on.
> . "Roundup", hardly. Three drives does not a roundup make:(
I was hoping they were going to teach us how to grind our spare DVDs (i.e. the developer ones Microsoft sends me every month which I never open) into a fine paste to use as weed killer.
If I could find a decent weed killer that I could mass-produce on my own, it would be much easier to mass-produce my killer weed.
Re:CDBurners not the end for high-capacity Zip dri
on
DVD Burner Round-up
·
· Score: 1
> Windows 98 first edition and Win95, neither of > which supported filesystems on USB devices
My Win98 FE box supports my USB digital camera as a filesystem. Hmm, not sure if it's read-only or not, though.
That said, I upgraded to IE6. Maybe MS secretly slurped in new USB and filesystem support DLLs, it wouldn't suprise me.
Or maybe the Kodak drivers work some magic.
Who knows, I don't get windows. Give me devfsadm/format/newfs/mount any day, at least I can understand what the hell is going on. Windows is worse than the freakin' automounter.
CD-ROMs are RAM. So are DVD-ROMs, regardless of how many extra plusses, minusses and Rs there may be in the marketing name.
The only kind of non-RAM ROM I can think of off the top of my head (which isn't part of a copy protection scheme) would by vinyl LPs and tapes with the read-only tag set.
Of course, you can access tracks on an LP out of order, too, so maybe even they don't count.
FIM Motorcycle racing is pretty damn exciting. So is WSBK. AMA is okay, but all the real talent seems to be on the world scene.
The New England Lawnmower Racing Association puts on some pretty good races, too, buy they're hard to find on television.
That said, you're right on the money with rally cars. If I had to buy a car, I would *so* want a WRX as my daily driver.
You're lucky you got to have the CD-ROM
on
Slackware Turns 10
·
· Score: 1
I had a box of floppies. I'd FTP a bunch of floppies from school, walk home, stuff them in the drive one at a time, and repeat.
I think it was 43 disks altogether; it took me several days to get it installed. What a pain in the ass.
Then I finally FTPed the whole distro down over a 28.8 link. Wow, that was nice, having the whole damned thing on my (then enormous 1054 MB) hard drive.
I'd be much more interested in a metric based on a number-of-statements metric.
This wouldn't be difficult to calculate: obviously, they have lexers and parsers which grok C code. This insulates the metric against coding styles, so that, say, some guy who litters his source with comments and braces, but writes the exact same effective code as another fellow will have statistically similar defect densities.
The comments and braces (and whatnot) aren't the only examples where this is useful, either.. Consider the two snippets which follow:
Even without comments, it's pretty plain to see that these segments, which pretty much all implement the same function with effectively the same code, with probably the same defects, have drastically different line counts -- but VERY similar statement counts. Remember, ++ side-effects, assignment operations, the three parts of the for(;;), would all be considered individual statements, even if they are not blatantly decomposed as such in the source code.
And, for the -fpedantic PITAs out there, no I haven't even bothered to compile the code (or really think about it). It's just a friggin' example!
Bio-weapons testing
on
SARS Contained
·
· Score: 2, Funny
> Make sure the seals on the building you use for bio-weapon testing are solid.
We don't use seals, they're just not smart enough, and every time the French guys start talking about them, the English guys start laughing. It's just too hard to get anything done with seals in Canada as long as the government continues to mandate a bilingual top-secret workforce.
We do use Dolphins, though. And they're solid; hell, they're built like brick shit houses! Members of the elite Dolphin Guard even have special filters covering their blow holes. (Previously, two Dolphin Guards were compromised by delayed-trigger grenades which were set to detonate when the guards got close to sensitive areas).
I didn't know about ltrace -- my RH 5.2 box doesn't have it. Hmm. I may have to upgrade, but I've been reticent to touch that (non-net-facing) box because as I understand it, most distros have dropped the UDB (Multia) support from their kernels/bootloaders.
I suppose I could go the upgrade route, but that'd mean a new kernel, which needs a new gcc, which needs a new glibc *argh*
Maybe I'll just dig up ltrace.c and see if it'll go.;)
But now I know why, due to the authors' comments. Thanks for the pointer to the TOC entry though, don't how I missed that.
For the readership out there, I'm sure those will be covered in the future; in the meantime, read your strace/ktrace/truss man pages. Run them on the application you're trying to RE before doing *anything* else. Sometimes, those dumps can provide *amazing* insight into the behaviour and structure of the program (particularly if you're good with 'grep'), especially if you're trussing and using the program interactively.
I can't believe they left out truss/strace/ktrace. Even without debugging symbols, these utilities can tell you what system calls are being called, when they are called, and what arguments are being passed.
truss under Solaris is even more useful than strace under Linux or ktrace under the BSDs; you can also trace function entry points into user-level ELF solibs.
Slashdot Mirror
> 1. No way to rename files without losing revision info.
,v files in the repository as you see fit
> 2. Ditto for moving files.
Move and rename are the same operation under any non-stupid operating system (such as UNIX and workalikes).
These are difficult with CVS, but not impossible. Here's how:
1. Make sure EVERYBODY has released the directories you're renaming to/from (unless they like surprises)
2. Log in to the CVS server
3. Rename the
4. Checkout $CVSROOT/CVSROOT
5. Make the rename/etc changes in your modules, etc files
6. Check in $CVROOT/CVSROOT
7. Check out the tree you want to work on
8. ???
9. Profit!
(I admit, step one is difficult with a large number of developers. Good thing we laid a bunch off.)
> 3. Can't handle symlinks.
True, but you don't need 'em 99.9% of the time. Just have your Makefiles create them:
$(LINKED_SOURCES):
[ -f "$(MORESRCDIR)/$@" ] && ln -s "$(MORESRCDIR)/$@" "$@"
The quotes are important if you have stupid people in your organization who think spaces belong in filenames. (And why does that only EVER happen with VB files? Gee, I wonder)
GBM would be relatively easy to "undo" with access to an appropriate lab. GBM ink is soaked into the paper; laser printing/photocopy ink is melted onto it.
It might be as simple as finding something which will react with toner to make it fluoresce under UV.
Wasn't that just a site hosting some guy's gaping asshole?
cat /etc/passwd | grep ^0:
Unless, of course, you were running UNIX boxes, in which case trying to log in as root was pretty stupid anyhow. Well, unless you had really custom kernels. But that seem like an enormous waste of effort.
FWIW, I'm 99.99% that's from COTK. I didn't read much Clancy in those days (still don't, actually), but I remember that ploy and time frame clearly. I'm pretty damned sure I was reading COTK at the time. The one about the soviet tank commander, right?
> Apparently it's absolutely gutless unless you wind
> it up enough for the turbo to kick in
Argh, that's unfortunate. I wonder if the WRC has the same motor?
On the other hand, I wonder how hard it would be to modify the WRX with the "VTEC" (quotes important) technology in the new Honda VFR 800 motorbike. It keeps half the exhaust valves closed 8000 rpm, allowing much more bottom end grunt than it would have other.
Probably cheaper to buy a new motor, though.
Still, depending on the turbo characteristics, that might okay. I ride a 250cc motorbike as my daily driver, and it is totally and completely limp below 8,000 RPM. Fortunately, after the first 8 grand there are another 6 to play with, and I'm quite good with the gear box.
I live about 5 miles from the Kingston Pen, and I can tell you that, without a shadow of a doubt, that nobody who has spent any time there will ever be reformed. This goes double for the guards -- the only difference between the guards and the inmates is what side of the bars they're on.
He was talking about *querying* the database, not *modifying* it.
Or, do you umask 077 all your files, and just change ownership to who think should view 'em?
It must be a bitch trying to keep track of all those DSOs.
> . "Roundup", hardly. Three drives does not a roundup make :(
I was hoping they were going to teach us how to grind our spare DVDs (i.e. the developer ones Microsoft sends me every month which I never open) into a fine paste to use as weed killer.
If I could find a decent weed killer that I could mass-produce on my own, it would be much easier to mass-produce my killer weed.
> Windows 98 first edition and Win95, neither of
> which supported filesystems on USB devices
My Win98 FE box supports my USB digital camera as a filesystem. Hmm, not sure if it's read-only or not, though.
That said, I upgraded to IE6. Maybe MS secretly slurped in new USB and filesystem support DLLs, it wouldn't suprise me.
Or maybe the Kodak drivers work some magic.
Who knows, I don't get windows. Give me devfsadm/format/newfs/mount any day, at least I can understand what the hell is going on. Windows is worse than the freakin' automounter.
Technically speaking, most ROM is RAM.
CD-ROMs are RAM. So are DVD-ROMs, regardless of how many extra plusses, minusses and Rs there may be in the marketing name.
The only kind of non-RAM ROM I can think of off the top of my head (which isn't part of a copy protection scheme) would by vinyl LPs and tapes with the read-only tag set.
Of course, you can access tracks on an LP out of order, too, so maybe even they don't count.
FIM Motorcycle racing is pretty damn exciting. So is WSBK. AMA is okay, but all the real talent seems to be on the world scene.
The New England Lawnmower Racing Association puts on some pretty good races, too, buy they're hard to find on television.
That said, you're right on the money with rally cars. If I had to buy a car, I would *so* want a WRX as my daily driver.
I had a box of floppies. I'd FTP a bunch of floppies from school, walk home, stuff them in the drive one at a time, and repeat.
I think it was 43 disks altogether; it took me several days to get it installed. What a pain in the ass.
Then I finally FTPed the whole distro down over a 28.8 link. Wow, that was nice, having the whole damned thing on my (then enormous 1054 MB) hard drive.
> USS Hilary and the USS Chelsea and the USS
> Monica and the USS Jennifer and the USS (etc).
Are you implying that Billy was wetting his willy in his little girl?
> You can't imagine the saga that has gone on trying to get body parts
;)
> that were made in France.
Body parts, hell, try getting *organs* that were made in France!
BTW, I feel for you. Have you tried ordering the same parts from Canada? Sometimes we get moto.stuff that you guys don't.
> Comments and spacing in source code have no effect at all on the
> result of the compilation (the binary (or whatever) produced).
Unless, of course, they are multi-line comments and the binaries aren't stripped -- in which case, the line numbers would change.
Yeah, I know, it's minor, but comments *can* slightly affect a binary.
I'd be much more interested in a metric based on a number-of-statements metric.
This wouldn't be difficult to calculate: obviously, they have lexers and parsers which grok C code. This insulates the metric against coding styles, so that, say, some guy who litters his source with comments and braces, but writes the exact same effective code as another fellow will have statistically similar defect densities.
The comments and braces (and whatnot) aren't the only examples where this is useful, either.. Consider the two snippets which follow:
char *strcpy(char *P, const char *Q) {
const char *p;
for (p = P; *Q; *p++ = *Q++);
*p = (char)0;
return P;
}
and
char *strcpy(char *P, const char *Q)
{
char *p = P;
while ((*p++ = *Q++));
*p = (char)0;
return P;
}
as well as
cdecl
char *strcpy(char *P, const char *Q)
{
char *p = P;
do
{
*p = *Q;
p++;
Q++;
} while (*Q);
return p;
}
Even without comments, it's pretty plain to see that these segments, which pretty much all implement the same function with effectively the same code, with probably the same defects, have drastically different line counts -- but VERY similar statement counts. Remember, ++ side-effects, assignment operations, the three parts of the for(;;), would all be considered individual statements, even if they are not blatantly decomposed as such in the source code.
And, for the -fpedantic PITAs out there, no I haven't even bothered to compile the code (or really think about it). It's just a friggin' example!
> Make sure the seals on the building you use for bio-weapon testing are solid.
We don't use seals, they're just not smart enough, and every time the French guys start talking about them, the English guys start laughing. It's just too hard to get anything done with seals in Canada as long as the government continues to mandate a bilingual top-secret workforce.
We do use Dolphins, though. And they're solid; hell, they're built like brick shit houses! Members of the elite Dolphin Guard even have special filters covering their blow holes. (Previously, two Dolphin Guards were compromised by delayed-trigger grenades which were set to detonate when the guards got close to sensitive areas).
You're right, the truss -u option appear under 2.8.
However, you can do most RE of 2.x binaries under 2.8, due to the wonderfully static ABI.
That's GNU/Public to you!
Let me know, and I'll find you some purchasers.
Good work so far, my other comment notwithstanding.
I didn't know about ltrace -- my RH 5.2 box doesn't have it. Hmm. I may have to upgrade, but I've been reticent to touch that (non-net-facing) box because as I understand it, most distros have dropped the UDB (Multia) support from their kernels/bootloaders.
;)
I suppose I could go the upgrade route, but that'd mean a new kernel, which needs a new gcc, which needs a new glibc *argh*
Maybe I'll just dig up ltrace.c and see if it'll go.
But now I know why, due to the authors' comments. Thanks for the pointer to the TOC entry though, don't how I missed that.
For the readership out there, I'm sure those will be covered in the future; in the meantime, read your strace/ktrace/truss man pages. Run them on the application you're trying to RE before doing *anything* else. Sometimes, those dumps can provide *amazing* insight into the behaviour and structure of the program (particularly if you're good with 'grep'), especially if you're trussing and using the program interactively.
I can't believe they left out truss/strace/ktrace. Even without debugging symbols, these utilities can tell you what system calls are being called, when they are called, and what arguments are being passed.
truss under Solaris is even more useful than strace under Linux or ktrace under the BSDs; you can also trace function entry points into user-level ELF solibs.
It was probably shar archive. That's where you bury a file(s) within a shell script, and it reconstitutes it on the other end.
.tar.gz files... or for that matter, .zip files, .a libraries, etc.
If that qualifies as "source", then so do drivers delivered in