Biometrics for security authentication is basically a flawed idea. This is why.
Imagine a biometrically-secure system, where the files you can access
are encrypted until you log in by verifying whatever you like (left thumbprint, left retina-print, etc.) Now imagine that you, a user or administrator of this system,
lose your key thumb or lose your left eye in a freak pizza accident.
One of two things happens. Either you forever lose all
your access to that data and system, or... someone can
edit the authorization protocols and let you back in.
That, my friend, is known as a back door. A system that
has one can't be considered secure anyway.
And you can't say that you can just go to the administrator
to change your authentication. If you own the system,
and you lose your eye, you've lost your root password
and are forever SOL. Or, as I said, you have another
way in, and so the biometric authentication was a sham anyway.
Biometric authentication for computer login authentication
is a bad idea. It does have its applications (physical site security, for example)
but it's a bad idea to bolt it on over a computer operating system, and expect security to result.
Most likely, someone else said what you've been
incorrectly credited as saying, and the DOJ just got the
attribution wrong. There were thousands of comments, after all.
I sympathize with your annoyance,
but I'm not sure whether a lot of effort is called
for in bringing this to the government's attention.
The misattribution doesn't seem all that germane
to the case, but it's natural that you feel
frustration. One wants to receive proper credit for
one's ideas.
No; in most cases, when galaxies collide,
no stars even collide at all. The interstellar
distances are great enough to make it
improbable, even with the millions and billions
of stars involved in such a collision.
So the same luck of numbers probably protects
Pioneer 10, and some of our other probes...
As long as they mark the cd, and people know ahead that the product will not work for them, they can protect all the cds they want to. People will just learn to avoid cds that are marked that way.
Yes, but this is still a problem for people who buy most of their CDs online,
and so don't have the opportunity to inspect the packaging
before making a purchase. Even if this settlement
makes music stores more willing to take back (rather than exchange for the same item)
non-compliant CDs, the hassle may make the whole experience just too irritating.
Imagine buying 10 CDs at cdnow and finding seven of them
have warnings on the label. So you send them back.
Then you open the other three, to find that two of them
have warnings inside the shrinkwrapped package. Even the
imaginary more liberal return policies are unlikely to help you now.
I have been looking for an automatic watch in this price range (in the US)-- everything I have found seems to be in the $400 range, which is more than I can spend.
I'm wearing a Timex automatic, with a list price of about $35, though I think it cost me more like $20. It's about five years old, but I think they may have discontinued the model not too long afterwards.
Which is a shame, really. Automatics are perfect for geeks.
No winding, no EMP vulnerability, easy to adjust*,
impossible to overwind, environmentally-friendly.
What's not to like?
* - maybe not that easy to adjust. Another post in this thread
mentioned taking a watch to a shop to have the battery changed.
Are we not geeks? All you need to do is crack the back,
and to tune an automatic, tweak a lever. It's not rocket science!
The main tarballs is a 12.5MB download, PGP encrypted with the "traditional magic words" (one of which is a big bird).
OK, it is cool that Zero Knowledge is making this available. But what are the "traditional magic words"? And how would that work, anyway, with PGP? A passphrase usually unlocks only a private key, which, erm, we don't have, as far as I know.
I think that would depend on the implementation
details of tee. It's certainly a valid
question. As I said, I don't know whether this
would work. Some programs are picky about reading
their input from pipes, but in my experience cdrecord
is fairly flexible that way.
And named pipes, unfortunately, have their own
quirks; but generally, if you set up the reading
process(es) before the writing process(es), results are gemerally good.
The AC is right; it wouldn't make sense to mount the ISO itself, as it's the image that's of use to the burner.
But here's an even better idea. Skip the ramdisk.
Instead, create a bunch of named pipes like np1..np10. Then start up a bunch of cdrecord instances, each reading from one of the named pipes. They should all block until they fill their input buffers.
Next, use tee to copy the ISO image from the hard
disk into each of the pipes.
That reads the ISO from the disk only once, and so should have the same performance advantages as setting it up in a tremendously large RAM disk (the contents of which might get swapped out anyway.)
Note that the final named pipe was redirected to, rather than named as an argument to tee. That avoids the need to write an extra copy out to/dev/null.
The Martin Pool/linuxcare.com.au project seems to be unrelated to the SnapFS in the original announcement, now owned by Mountain View Data. There's a README on the Pool project here. It does seem to be dead, which is OK since it didn't offer the full filesystem rollback capability. In addition, it was a true filesystem, unlike the other, which was designed to sit in another layer above Ext3.
If anyone has an old tarball of the now-MountainView SnapFS, please let me know...
Factors are going to include the speed of the
drives holding the.iso images, the number of
CD burners per SCSI bus, and the speed that you
are trying to burn the disks at (eg. 4x). The idea of using a RAM disk to eliminate the hard drive variable has some merit, but unless you've got a gig of RAM or so, you'll only be able to burn one image at a time onto those multiple disks.
But here's an unrelated thought. You say these CDs are to contain 30 minute mono lectures. A CD will hold 60 minutes easily. Why not put two lectures per CD and save on your overhead in loading and unloading the disks?
You could take it even further by recording one lecture in the left audio channel, and another in the right, to fit four lectures per disk. It might be worth considering.
That is exactly the concept I'm looking for! Unfortunately it seems to be quite dead. Here's what I found with Google.
A sourceforge project with no files uploaded, no description, and a few messages asking, "What happened?"
A glossary which describes SnapFS as "A defunct experimental filesystem". There's also a broken link to linuxcare.com.au/projects/snapfs .
A diary entry from somebody named Martin Pool. On 18 August 2000 he writes,
I wrote up some documentation for my
snapfs filesystem, which has been shelved for some months now. I get mail every so often asking what happened to it, so it seemed good to answer it once and for all. Perhaps I'll get back to it eventually.
And of course, Mountain View Data (or the equivalent snapfs.org),
which now owns the project and seems to have renamed it "MVD Snap". But there is very little information here, and nothing to download.
Is it legitimate for SnapFS to go missing like this? The link you gave says that SnapFS is under the GPL.
So doesn't it have to be available somewhere in a free and downloadable form?
Someone else mentioned this too, but can you do LVM in Linux easily? If so, set up to do snapshots before a big upgrade. A snapshot is a virtual copy of your data. When a file is added or changed only the extra info is written to a seperate place on the disk. So, you end up with two "copies" of the data but it doesn't use up a ton of disk space.
That's just about the idea I was looking for;
or, at least, half of it. (Thanks, Morzel, for the link
to the white paper.) LVM seems to handle the "commit"
half of the problem cleanly and efficiently (by just deleting the snapshot), but the "rollback"
problem seems to remain. If I can't redesignate my
"snapshot" as the new "mainline," then I don't have a painless way
to do a "rollback."
Others have mentioned using rdist or tar, which are not
unreasonable ideas. But this is my home server, with more space than
anything else I've got; so those solutions just require me to have
another server, both bigger and more stable,
and to which the same questions would ultimately apply.
So, my ideal solution would be the all-in-one-box answer, if it can be done.
> Regardless, this is not what
the article submitter was talking about at all.
+1, Insightful.
It is one of the dangers of Debian; upgrade to the latest unstable apt -> nuked package db,
That's only a minor issue. Although I *have* had
package DB corruption, it's usually been due to a
daemon restart causing a sudden system freeze. And using
dselect to rebuild the package database takes care of it.
More serious is when an update breaks, say, Ethernet or Modem access and I can no longer connect to the Net to fetch repaired packages.
That's when I'd love to be able to roll back to a known working configuration.
If your filesystem is badly corrupted - is it possible to restore the last backup?
True, but I'm looking for a filesystem solution
here. If the filesystem is hosed, the solution is
hosed too. It's inadvertently bad file system
contents that I'd like to be able to roll
back if they turn out to be Not So Hot.
This idea would also be very handy for other
admin tasks. Say you have X working but want to
try out a new and possibly better driver. There
may be files all over the place to tweak to try to
get that up and running, and if you fail, you may
lose graphics altogether. So you have to keep careful
track of what you do, so that you can undo it. But
with this sort of system, you could place a mark and play,
knowing that you could revert to a working set of
config files if you're ready to give up. And the
system would be doing the tedious recordkeeping
for you. Doesn't that sound great, in theory?
My preferred embodiment for this scheme would
be one that you could "rollback" even after a few
reboots. But let's see what's out there.
Because Windows diddles with the hardware clock directly, it can't be used (directly) as a UTC time source for UNIX.
It can if you tell Winblows that your local time zone is UTC,
and then correct it in your head when you look at the clock.
Or is that just too damn geeky?
That's interesting. Seagate drives used to be famous for having a sudden death problem called "stiction", where the heads would fuse to the platters and the drives would become good only for so much landfill.
Perhaps they solved that difficulty, and some time ago, but I'm only guessing because Goodle for "stiction" doesn't turn up Seagate anywhere in the top 10. But "seagate stiction" at least shows me that some people out there remember this. Some pages call it "infamous." When was this solved, if it was?
That it's on your brother's birthday is the whole
of the coincidence. A little thought will reveal
that everyone hits the 15000000 minute mark
and the 250000 hour mark at the same moment.
My guess is you don't have DMA turned on on your DVD-ROM drive.
You know what? You were absolutely right. Thank you! That makes a for a major improvement. My audio still clicks a little, but it's 97% better.
You don't happen to also know the Debian-approved standard way to make hdparm settings reinstate upon reboot, do you? (I can roll my own init.d scripts, but it's best to go with the standard methods, where they exist.)
the downside of DVDs is you can't make a backup copy of it very easily. Sure, there is illegal software to rip them onto your hard drive
Hmm? By coincidence, tonight I borrowed a DVD disc and tried ogle on my new system for the very first time. The audio glitched every time the software accessed the DVD drive.
Which is probably to be expected; I don't have everything tuned jest perfect on this new box yet.
So I tried: dd if=/dev/dvd of=movie.dvd and let that run.
Took a while. I didn't know DVDs could handle 8GB of data. But that was the
'ripping' step. Is dd illegal contraband software?
Ogle did much better reading the movie off my hard drive than it had off the DVD directly. Still some audio and video glitches, but
that's to be expected on the bleeding edge of beta Linux drivers.
I can still consider it a moral victory that it worked at all.
And to my dismay it doesn't include Xenix. Would have been nice to finally have an open source Microsoft product
That's almost certainly why Xenix isn't in there.
In the last days of SCO, they wanted to release the
Xenix source code, but were held up in negotiations
with Microsoft in trying to get the rights released.
This is very cool indeed. These early UNIXes weren't
at all feature-rich, compared to what we have now,
but they were compact. Tight. Elegant.
Worthy of inspection and study. And more accessible
for that purpose because 5000 lines of code is more
browsable than 500000. (Pulled both of those numbers
out of goatse-guy's orifice.)
the difference between civil law and criminal law
is that in civil law, the plaintiff can be anyone, while in criminal law,
only the government can bring the case.
Slashdot Mirror
If you can't recognize satire, when you see it, as the often profound social commentary that it can be, then I recommend you give 1984 a miss.
Carroll made a good point, I thought. If we don't object to nonsense, the nonsense will only get worse.
Imagine a biometrically-secure system, where the files you can access are encrypted until you log in by verifying whatever you like (left thumbprint, left retina-print, etc.) Now imagine that you, a user or administrator of this system, lose your key thumb or lose your left eye in a freak pizza accident.
One of two things happens. Either you forever lose all your access to that data and system, or ... someone can
edit the authorization protocols and let you back in.
That, my friend, is known as a back door. A system that
has one can't be considered secure anyway.
And you can't say that you can just go to the administrator to change your authentication. If you own the system, and you lose your eye, you've lost your root password and are forever SOL. Or, as I said, you have another way in, and so the biometric authentication was a sham anyway.
Biometric authentication for computer login authentication is a bad idea. It does have its applications (physical site security, for example) but it's a bad idea to bolt it on over a computer operating system, and expect security to result.
I sympathize with your annoyance, but I'm not sure whether a lot of effort is called for in bringing this to the government's attention. The misattribution doesn't seem all that germane to the case, but it's natural that you feel frustration. One wants to receive proper credit for one's ideas.
So the same luck of numbers probably protects Pioneer 10, and some of our other probes ...
Yes, but this is still a problem for people who buy most of their CDs online, and so don't have the opportunity to inspect the packaging before making a purchase. Even if this settlement makes music stores more willing to take back (rather than exchange for the same item) non-compliant CDs, the hassle may make the whole experience just too irritating.
Imagine buying 10 CDs at cdnow and finding seven of them have warnings on the label. So you send them back. Then you open the other three, to find that two of them have warnings inside the shrinkwrapped package. Even the imaginary more liberal return policies are unlikely to help you now.
I'm wearing a Timex automatic, with a list price of about $35, though I think it cost me more like $20. It's about five years old, but I think they may have discontinued the model not too long afterwards.
Which is a shame, really. Automatics are perfect for geeks. No winding, no EMP vulnerability, easy to adjust*, impossible to overwind, environmentally-friendly. What's not to like?
* - maybe not that easy to adjust. Another post in this thread mentioned taking a watch to a shop to have the battery changed. Are we not geeks? All you need to do is crack the back, and to tune an automatic, tweak a lever. It's not rocket science!
OK, it is cool that Zero Knowledge is making this available. But what are the "traditional magic words"? And how would that work, anyway, with PGP? A passphrase usually unlocks only a private key, which, erm, we don't have, as far as I know.
River Phoenix? Open Sesame Street?
A question of legal philosophy: is it illegal to call "Fire" if the theatre is, in fact, alight?
And named pipes, unfortunately, have their own quirks; but generally, if you set up the reading process(es) before the writing process(es), results are gemerally good.
But here's an even better idea. Skip the ramdisk. Instead, create a bunch of named pipes like np1..np10. Then start up a bunch of cdrecord instances, each reading from one of the named pipes. They should all block until they fill their input buffers.
Next, use tee to copy the ISO image from the hard disk into each of the pipes.
That reads the ISO from the disk only once, and so should have the same performance advantages as setting it up in a tremendously large RAM disk (the contents of which might get swapped out anyway.)
Note that the final named pipe was redirected to, rather than named as an argument to tee. That avoids the need to write an extra copy out to /dev/null.
Will it work? You'd have to try it...
The Martin Pool/linuxcare.com.au project seems to be unrelated to the SnapFS in the original announcement, now owned by Mountain View Data. There's a README on the Pool project here. It does seem to be dead, which is OK since it didn't offer the full filesystem rollback capability. In addition, it was a true filesystem, unlike the other, which was designed to sit in another layer above Ext3.
If anyone has an old tarball of the now-MountainView SnapFS, please let me know...
But here's an unrelated thought. You say these CDs are to contain 30 minute mono lectures. A CD will hold 60 minutes easily. Why not put two lectures per CD and save on your overhead in loading and unloading the disks?
You could take it even further by recording one lecture in the left audio channel, and another in the right, to fit four lectures per disk. It might be worth considering.
- A sourceforge project with no files uploaded, no description, and a few messages asking, "What happened?"
- A glossary which describes SnapFS as "A defunct experimental filesystem". There's also a broken link to linuxcare.com.au/projects/snapfs .
- A diary entry from somebody named Martin Pool. On 18 August 2000 he writes,
- And of course, Mountain View Data (or the equivalent snapfs.org),
which now owns the project and seems to have renamed it "MVD Snap". But there is very little information here, and nothing to download.
Is it legitimate for SnapFS to go missing like this? The link you gave says that SnapFS is under the GPL. So doesn't it have to be available somewhere in a free and downloadable form?Thanks to everyone for all the help!
That's just about the idea I was looking for; or, at least, half of it. (Thanks, Morzel, for the link to the white paper.) LVM seems to handle the "commit" half of the problem cleanly and efficiently (by just deleting the snapshot), but the "rollback" problem seems to remain. If I can't redesignate my "snapshot" as the new "mainline," then I don't have a painless way to do a "rollback."
Others have mentioned using rdist or tar, which are not unreasonable ideas. But this is my home server, with more space than anything else I've got; so those solutions just require me to have another server, both bigger and more stable, and to which the same questions would ultimately apply. So, my ideal solution would be the all-in-one-box answer, if it can be done.
+1, Insightful.
That's only a minor issue. Although I *have* had package DB corruption, it's usually been due to a daemon restart causing a sudden system freeze. And using dselect to rebuild the package database takes care of it.
More serious is when an update breaks, say, Ethernet or Modem access and I can no longer connect to the Net to fetch repaired packages. That's when I'd love to be able to roll back to a known working configuration.
True, but I'm looking for a filesystem solution here. If the filesystem is hosed, the solution is hosed too. It's inadvertently bad file system contents that I'd like to be able to roll back if they turn out to be Not So Hot.
This idea would also be very handy for other admin tasks. Say you have X working but want to try out a new and possibly better driver. There may be files all over the place to tweak to try to get that up and running, and if you fail, you may lose graphics altogether. So you have to keep careful track of what you do, so that you can undo it. But with this sort of system, you could place a mark and play, knowing that you could revert to a working set of config files if you're ready to give up. And the system would be doing the tedious recordkeeping for you. Doesn't that sound great, in theory?
My preferred embodiment for this scheme would be one that you could "rollback" even after a few reboots. But let's see what's out there.
Many of the machines in this guy's collection came from the Boston Computer Museum when it shut down, not that long ago.
I don't see where he said that.
Because Windows diddles with the hardware clock directly, it can't be used (directly) as a UTC time source for UNIX.
It can if you tell Winblows that your local time zone is UTC, and then correct it in your head when you look at the clock. Or is that just too damn geeky?
No doubt, the brilliant effort of Tom Lehrer.
That's interesting. Seagate drives used to be famous for having a sudden death problem called "stiction", where the heads would fuse to the platters and the drives would become good only for so much landfill.
Perhaps they solved that difficulty, and some time ago, but I'm only guessing because Goodle for "stiction" doesn't turn up Seagate anywhere in the top 10. But "seagate stiction" at least shows me that some people out there remember this. Some pages call it "infamous." When was this solved, if it was?
That it's on your brother's birthday is the whole of the coincidence. A little thought will reveal that everyone hits the 15000000 minute mark and the 250000 hour mark at the same moment.
You know what? You were absolutely right. Thank you! That makes a for a major improvement. My audio still clicks a little, but it's 97% better.
You don't happen to also know the Debian-approved standard way to make hdparm settings reinstate upon reboot, do you? (I can roll my own init.d scripts, but it's best to go with the standard methods, where they exist.)
Hmm? By coincidence, tonight I borrowed a DVD disc and tried ogle on my new system for the very first time. The audio glitched every time the software accessed the DVD drive. Which is probably to be expected; I don't have everything tuned jest perfect on this new box yet.
So I tried: dd if=/dev/dvd of=movie.dvd and let that run. Took a while. I didn't know DVDs could handle 8GB of data. But that was the 'ripping' step. Is dd illegal contraband software?
Ogle did much better reading the movie off my hard drive than it had off the DVD directly. Still some audio and video glitches, but that's to be expected on the bleeding edge of beta Linux drivers. I can still consider it a moral victory that it worked at all.
That's almost certainly why Xenix isn't in there. In the last days of SCO, they wanted to release the Xenix source code, but were held up in negotiations with Microsoft in trying to get the rights released.
This is very cool indeed. These early UNIXes weren't at all feature-rich, compared to what we have now, but they were compact. Tight. Elegant. Worthy of inspection and study. And more accessible for that purpose because 5000 lines of code is more browsable than 500000. (Pulled both of those numbers out of goatse-guy's orifice.)
Can the government bring a civil case?