We already rely on non-free software for too much. Ever heard of netscape? The only free alternatives at this time are Mozilla, which is appropriately named for its monstrous size (32MB of memory won't handle it so I'm stuck with netscape sans java), and gzilla/armadillo, which is an early alpha lynx with pictures and crashes (for now). Lynx doesn't count since it can't do tables (I don't care about pictures and frames, but I have to have my tables)
I still agree we should avoid further intrusions of important non-free software into our pure hard disks (by important I don't mean simple stuff like xsnow), and Netscape is one example of what happens; people don't even think about this anymore. Someone port Kmeleon to Linux please!
DC is not in danger if people reverse-engineer their software, even if their software is indirectly their only source of income. Here's why:
DC distributes their software with the scanner Anyone who gets the scanner is not going to bother getting software somewhere else if it already comes with it. Not many people wipe their hard drive and install Linux, *BSD, etc. when they get a new computer; they keep Windows.
The local software doesn't do everything I'm not certain of this, but I assume the way the software works is that it deciphers the bar code, then sends the bar code and manufacturer code to some website where it returns a URL referrer to the web page belonging to the product. The money is being made off of hosting those companies' barcodes on that central server. I assume it works this way, otherwise people would have to get a new software version with each company agreeing to use the barcodes.
One may counter this argument by saying "Well, what if someone reverse-engineers the server and offers a rival barcode service?" This is no threat to DC, since to use another server a different version of software would be needed, which means people would have to install it on their own, and thus I refer you to my first point.
The only danger to DC is that it may look silly in the eyes of other companies for losing control of its scanners, but I doubt that most of the people who picked up the scanner immediately got to work reverse-engineering it on their Linux-powered web server at home.
If any DC marketing people are reading this, it has been proven before that you cannot keep people from trying to reverse-engineer the software. A few examples are DeCSS (even if 2600 lost, it's only a US precedent...) and the Netpliance I-Opener. Netpliance, after the slashdot story about putting Linux on it, reportedly made it impossible to do this. If you are really paranoid here, just do something like that, use DES encryption on the barcode or something.
.tgz's are used to package the various OpenBSD programs in binary form (which are only a few big generalized packages) but tarballs can't do everything in binary packaging.
The advantages to package management I've seen are:
- pre/post-install/removal scripts (tex stuff needs to update the hash, sshd needs to get started after install, etc.)
- file verification (rpm can do this with rpm -V, does checksumming, etc on all files)
- upgrading; if you install a new version of a program it should be smart enough to know whether or not to overwrite your config files which may be important, i.e. for linux upgrading LILO shouldn't overwrite lilo.conf
- dependencies/conflicts, which sometimes get annoying
- provides (in Debian, for example, packages can recommend www-browser, which is provided by lynx, netscape, chimera, etc.)
- previewing; before installing a package you can get version info, descriptions, etc. and yes you could make a simple script to make tar display the file/usr/share/doc/<package-name>/README but this isn't much functionality here.
I do agree that.tar.gz is great especially because of the excellent functionality of GNU tar, and I agree that it's the most cross-platform solution (what unix doesn't have at least some kind of tar??) but this was not designed for such complex packaging as.rpm,.deb, and the others.
How will all the BSDs choose an appropriate lisence for the packaging programs though? Seems like since each BSD has a different license they will all want the package system to be in their own native license, or have I been using Debian too long?
Still this is an interesting concept, especially since not everyone can write portable code, and porting can then be done by one person and distributed as packages (I ran into this problem trying to get Mozilla to run on Irix, just reading the process turned me off)
I also wonder what packaging systems it wil be based off of; will it be like RPM with lots of functionality but confusing or absent categorization (my RPM databases always turned into one package per category because I'd install mandrake or SuSE packages on top of RedHat), or will it be like.deb with a simpler style?
Never mind, misinterpretation of the:Cue:Cat info on the site referenced; I was interpreting the first field, which is obviously the ID of the company since most of the stuff I scanned was from Tandy (Radio Shack). So how does that work? It's wierd how both the first field and the third seem to be parseable in the same way; I haven't seen all the source from all the hacks out there, but that seems interesting to me, and makes the difference between the first and third field unclear on cuecat.mp3car.com.
Mine only scans the barcode "000000001176", but it does differentiate between the type (ISBN, UPC, etc.) and the last period-separated field is always different. What's going on? I didn't install the software; does the CD somehow initialize it?
The point is, as I understand it, is that SANE is probably an overkill; just make a program that reads stdin and prints the info out, assuming the software can be easily reverse-engineered.
Why would someone go to such length to encode a barcode scanner data stream anyway? It sounds like it's trying to be incompatible with everything, like.doc (well, not that bad)
If these torpedoes are really going mach 2 (whatever that means; speed of sound in water or air?) then it cannot home in on the ship because the sounds from the submarine go slower than the torpedo!! Even so, if the torpedo began to home in on the Kursk the turn it would have to make would inevitable be so wide that it would not be able to maintain the signal once it was at the greatest distance away.
The only catch is that I think sound goes faster in water than air. And I don't know how knots translate to sound speed.
> Someone has to read between the lines of all the GUI's and wizards and actually know what is going on.
Really? That's kinda hard to do unless you get a book on every single service you run on your machine. Either that or get a simple solution that tells you what it's doing, a.k.a. unix. I believe OpenBSD includes "no default passwords" in its boast "Three years without a remote hole in the default install!"
A system should be secure without intervention. I shouldn't have to make any change and my system should be at least reasonably secure. If I have to have a checklist sticky note on the NT jewel case for every system I install, the NOS is obviously not doing its job. You can make almost any OS secure if you change enough things and apply enough patches, but this is not a measure of security.
I don't know much about NT, but the account should be disabled by default, and these books you refer to should say "The absolute first thing you must do is enable the account and change the password."
I feel the same way about piranha; the account should have been disabled, thus requiring a password to be set (since disabling an account is just setting the password to "*")
I cannot find out what a TiVo even is! The page with the link has a FAQ that points to tivocommunity.com but their FAQ is basically a rephrased slashdot FAQ if you're trying to find out what IMHO stands for or something.
So could some karma whores post a few links or something?
Right now a mission to Pluto is the most convenient time it's going to get; as I recall Pluto is currently closer to the sun than Neptune, meaning a mission 10 years from now (when it was planned, about) would be much better than a mission 30 or 40 years from now. We also want to rendezvous with Pluto along the plane of the solar system (Pluto's orbit is askew) so the best time to launch a probe would be within the next 10 years or so, so that it can meet up with Pluto close to where it intersects with the Solar system, then travel on to the Kuiper belts. Otherwise it will have to travel up and over (direct diagonal would be disaster; no gravity slingshots). Too bad the article doesn't say which missions will be cancelled. Or did I miss it?
Perhaps NASA is considering new propulsion techniques we've heard so much about on slashdot, lie solar sails. This would be great for several of the missions to the outer planets. Maybe this "delay" is just a way to experiment with using these technologies.
Space isn't going to get cheaper until we make more scientific advances. Unfortunately that means staying here in earth orbit (yes I mean ISS) and developing these technologies, like maybe some Ion engines or some other way of relying on electricity more, and making fuel cells more effieient. That alone would cut costs immensely since we don't have to worry about the bulk or expense of propellent.
However do we really have that kind of time here? That could take as long as a decade. How long will it be until all interest in space dies out and is no longer a New and Cool Thing, and instead something to be taken for granted like every other technological advance?
I think it may be better in the end, ideally, to let our space program mature before we try any new stunts, but I think we also have a lot of important missions to follow up on before the interest runs out, like the possibility of life on Mars and Europa. I eagerly await their outcomes, but many people may lose interest before long.
No. But someone had to say it, right? I guess you could get a WHOLE LOT of them in a very small area though. And you thought the G4 Cubes were compact and stackable...
I didn't see this in the comments (but given the laws of probability, with 800 and 135 above 2 comments it probably is)
You cannot add up the total number of Linux bugs by summing the individual ones form each distribution. Each distribution has a lot of the same programs. For example, when the wu-ftpd exploit was found, that is a common package. Almost every distribution has that, and thus that package was probably counted in Moody's "bug list" 5 or 6 times! I can't imagine how many times he must have covered the suid exploit in kernels < 2.2.16.
Besides a lot of the packages have version numbers < 1!! If you don't want to risk buggy software, don't install those! Most packages I've seen with version numbers > 1 are quite stable and effective, it's just the 0.x packages that are somewhat dangerous, and in some distributions this isn't true because they fix bugs independently but keep the version number the same! For example nano 0.8.6 (free pico clone) in Debian is as stable as the latest devel. releases, now a 0.9.14, but just without the other features. If you go download nano 0.8.6 from the developer, it will be full of bugs and probably will crash if you try to mark text.
If you want to find out how many Linux bugs there are in all the packages (which isn't fair anyway since MS has lots of bugs in the products that don't ship with windows) you have to keep a count of what packages are common to multiple distributions, and also unique bugs (which should probably be thrown out since they're insignificant to the OS as a whole, like a typo in the intaller). If you did this you would find surprisingly fewer bugs in Linux.
Also NT doesn't come with three mainstream text editors (vi, emacs, pico, maybe also joe, ae, etc.), two or three desktop environments still somewhat in development (GNOEM, KDE, xfce), three or four graphical shells/file managers (GNOME's, KDE's, Midnight Commander). The point is that when you give people this much choice and flexibility you increase the chance of bugs, okay. If NT gives you one of each of those and that one is buggy, there is reason to complain. In Linux, if GNOME crashes too much for you (I don't think so for the record) or is too slow, you can always switch to KDE. If vi is too cryptic, use emacs. If pine can't refresh that top blank row on the screen, use mutt.
I did that last year in 10th grade in pascal and finished it in a week, because I enjoyed it so much. I spent the rest of the month (when everyone else was scrambling to finish) adding a god mode that let you do all sorts of quick wins, like cruise missiles, jump to any room, and infinite HP.
RedHat's basic OS strategy seems to be to release a.0 with lots of new stuff and improvements, but with it inevitably comes lots of bugs. For example 6.0 had 2.2 kernel, libc6, etc. the first distribution to do that. But it was terrible, lots of problems and bugs that I have seen on many 6.0 systems, like the mysterious "Shutting down X font server [FAILED]" and "nfsd: terminating on signal 9" messages every time to halt/reboot. The version of GNOME it came with was also really unstable.
Then RedHat fixes most of these problems in a.1 release. I was much happier with 6.1 when I quickly installed it. It worked much better but I didn't appreciate the unmaintained/undocumented text mode installer, or the fact it didn't install a kernel with kernel module loader.
I don't know about the.2 releases, but I presume they fix more problems, making them the most stable.
So imaging what a beta of an unstable product will be... 2.4.0-test4pre2, gcc-3.0pre5, etc. I would stick with 6.2 unless you're really brave.
You bought a door lock from a company. However the lock model is defective. Which is more likely to get broken into:
1. The company issues a public recall of the door lock and offers free replacement.
2. The company doesn't tell anybody, but changes it in their next model.
Another example: remember that pirranha hole in RedHat 6.2 a while back? What if RedHat didn't tell anybody, and instead just fixed it to put in 7.0, or quietly put it in the updates section? The latter possibility wouldn't even get it to all the mirrors before 7.0 came out; how is this security?
Security through obscurity has been proven not to work through practice.
We aren't disclosing holes just to the kiddies, we're disclosing it to everybody willing to listen. That means people can know when there's a problem, to which they have every right. Otherwise if one person found this hole, that information will get passed on and on until you get cracked and have no idea why. Security through obscurity is only appealing to lazy sysadmins who don't want to bother with actively keeping their system secure (by visiting bugtraq etc.) and instead want it to be done passively (Microsoft releases a new SP) This is no way to maintain a server and thus no way to look at security.
Slashdot Mirror
I still agree we should avoid further intrusions of important non-free software into our pure hard disks (by important I don't mean simple stuff like xsnow), and Netscape is one example of what happens; people don't even think about this anymore. Someone port Kmeleon to Linux please!
DC is not in danger if people reverse-engineer their software, even if their software is indirectly their only source of income. Here's why:
DC distributes their software with the scanner Anyone who gets the scanner is not going to bother getting software somewhere else if it already comes with it. Not many people wipe their hard drive and install Linux, *BSD, etc. when they get a new computer; they keep Windows.
The local software doesn't do everything I'm not certain of this, but I assume the way the software works is that it deciphers the bar code, then sends the bar code and manufacturer code to some website where it returns a URL referrer to the web page belonging to the product. The money is being made off of hosting those companies' barcodes on that central server. I assume it works this way, otherwise people would have to get a new software version with each company agreeing to use the barcodes.
One may counter this argument by saying "Well, what if someone reverse-engineers the server and offers a rival barcode service?" This is no threat to DC, since to use another server a different version of software would be needed, which means people would have to install it on their own, and thus I refer you to my first point.
The only danger to DC is that it may look silly in the eyes of other companies for losing control of its scanners, but I doubt that most of the people who picked up the scanner immediately got to work reverse-engineering it on their Linux-powered web server at home.
If any DC marketing people are reading this, it has been proven before that you cannot keep people from trying to reverse-engineer the software. A few examples are DeCSS (even if 2600 lost, it's only a US precedent...) and the Netpliance I-Opener. Netpliance, after the slashdot story about putting Linux on it, reportedly made it impossible to do this. If you are really paranoid here, just do something like that, use DES encryption on the barcode or something.
.tgz's are used to package the various OpenBSD programs in binary form (which are only a few big generalized packages) but tarballs can't do everything in binary packaging.
/usr/share/doc/<package-name>/README but this isn't much functionality here.
.tar.gz is great especially because of the excellent functionality of GNU tar, and I agree that it's the most cross-platform solution (what unix doesn't have at least some kind of tar??) but this was not designed for such complex packaging as .rpm, .deb, and the others.
The advantages to package management I've seen are:
- pre/post-install/removal scripts (tex stuff needs to update the hash, sshd needs to get started after install, etc.)
- file verification (rpm can do this with rpm -V, does checksumming, etc on all files)
- upgrading; if you install a new version of a program it should be smart enough to know whether or not to overwrite your config files which may be important, i.e. for linux upgrading LILO shouldn't overwrite lilo.conf
- dependencies/conflicts, which sometimes get annoying
- provides (in Debian, for example, packages can recommend www-browser, which is provided by lynx, netscape, chimera, etc.)
- previewing; before installing a package you can get version info, descriptions, etc. and yes you could make a simple script to make tar display the file
I do agree that
How will all the BSDs choose an appropriate lisence for the packaging programs though? Seems like since each BSD has a different license they will all want the package system to be in their own native license, or have I been using Debian too long?
.deb with a simpler style?
Still this is an interesting concept, especially since not everyone can write portable code, and porting can then be done by one person and distributed as packages (I ran into this problem trying to get Mozilla to run on Irix, just reading the process turned me off)
I also wonder what packaging systems it wil be based off of; will it be like RPM with lots of functionality but confusing or absent categorization (my RPM databases always turned into one package per category because I'd install mandrake or SuSE packages on top of RedHat), or will it be like
Never mind, misinterpretation of the :Cue:Cat info on the site referenced; I was interpreting the first field, which is obviously the ID of the company since most of the stuff I scanned was from Tandy (Radio Shack). So how does that work? It's wierd how both the first field and the third seem to be parseable in the same way; I haven't seen all the source from all the hacks out there, but that seems interesting to me, and makes the difference between the first and third field unclear on cuecat.mp3car.com.
Mine only scans the barcode "000000001176", but it does differentiate between the type (ISBN, UPC, etc.) and the last period-separated field is always different. What's going on? I didn't install the software; does the CD somehow initialize it?
- No keyboard
- Color/Aqua
- Odd shape
This must be the Apple G13 Donut.
(Please don't think of this as flamebait, it's a joke)
A G4 Cube is a vegetable????
Sorry, couldn't resist...
The point is, as I understand it, is that SANE is probably an overkill; just make a program that reads stdin and prints the info out, assuming the software can be easily reverse-engineered. .doc (well, not that bad)
Why would someone go to such length to encode a barcode scanner data stream anyway? It sounds like it's trying to be incompatible with everything, like
RedHat acquires Amiga.
If these torpedoes are really going mach 2 (whatever that means; speed of sound in water or air?) then it cannot home in on the ship because the sounds from the submarine go slower than the torpedo!! Even so, if the torpedo began to home in on the Kursk the turn it would have to make would inevitable be so wide that it would not be able to maintain the signal once it was at the greatest distance away.
The only catch is that I think sound goes faster in water than air. And I don't know how knots translate to sound speed.
Well, time to wait three more months for the 2.4 kernel to include THIS too...
Stop inventing standards so fast! It's GNU, we have to play catch-up! (most of the time, this is true)
Using RAMBUS-only also cuts out the smart market :-)
> Someone has to read between the lines of all the GUI's and wizards and actually know what is going on.
Really? That's kinda hard to do unless you get a book on every single service you run on your machine. Either that or get a simple solution that tells you what it's doing, a.k.a. unix. I believe OpenBSD includes "no default passwords" in its boast "Three years without a remote hole in the default install!"
A system should be secure without intervention. I shouldn't have to make any change and my system should be at least reasonably secure. If I have to have a checklist sticky note on the NT jewel case for every system I install, the NOS is obviously not doing its job. You can make almost any OS secure if you change enough things and apply enough patches, but this is not a measure of security.
I don't know much about NT, but the account should be disabled by default, and these books you refer to should say "The absolute first thing you must do is enable the account and change the password."
I feel the same way about piranha; the account should have been disabled, thus requiring a password to be set (since disabling an account is just setting the password to "*")
Who would put a picture of a Qt coder in their screenshot? Where's their pictures of Natalie Portman? Sheesh.
I cannot find out what a TiVo even is! The page with the link has a FAQ that points to tivocommunity.com but their FAQ is basically a rephrased slashdot FAQ if you're trying to find out what IMHO stands for or something.
So could some karma whores post a few links or something?
Some of these missions are very time-dependent.
Right now a mission to Pluto is the most convenient time it's going to get; as I recall Pluto is currently closer to the sun than Neptune, meaning a mission 10 years from now (when it was planned, about) would be much better than a mission 30 or 40 years from now. We also want to rendezvous with Pluto along the plane of the solar system (Pluto's orbit is askew) so the best time to launch a probe would be within the next 10 years or so, so that it can meet up with Pluto close to where it intersects with the Solar system, then travel on to the Kuiper belts. Otherwise it will have to travel up and over (direct diagonal would be disaster; no gravity slingshots). Too bad the article doesn't say which missions will be cancelled. Or did I miss it?
Perhaps NASA is considering new propulsion techniques we've heard so much about on slashdot, lie solar sails. This would be great for several of the missions to the outer planets. Maybe this "delay" is just a way to experiment with using these technologies.
Space isn't going to get cheaper until we make more scientific advances. Unfortunately that means staying here in earth orbit (yes I mean ISS) and developing these technologies, like maybe some Ion engines or some other way of relying on electricity more, and making fuel cells more effieient. That alone would cut costs immensely since we don't have to worry about the bulk or expense of propellent.
However do we really have that kind of time here? That could take as long as a decade. How long will it be until all interest in space dies out and is no longer a New and Cool Thing, and instead something to be taken for granted like every other technological advance?
I think it may be better in the end, ideally, to let our space program mature before we try any new stunts, but I think we also have a lot of important missions to follow up on before the interest runs out, like the possibility of life on Mars and Europa. I eagerly await their outcomes, but many people may lose interest before long.
Imagine a beowulf cluster of these!
No. But someone had to say it, right? I guess you could get a WHOLE LOT of them in a very small area though. And you thought the G4 Cubes were compact and stackable...
I didn't see this in the comments (but given the laws of probability, with 800 and 135 above 2 comments it probably is)
You cannot add up the total number of Linux bugs by summing the individual ones form each distribution. Each distribution has a lot of the same programs. For example, when the wu-ftpd exploit was found, that is a common package. Almost every distribution has that, and thus that package was probably counted in Moody's "bug list" 5 or 6 times! I can't imagine how many times he must have covered the suid exploit in kernels < 2.2.16.
Besides a lot of the packages have version numbers < 1!! If you don't want to risk buggy software, don't install those! Most packages I've seen with version numbers > 1 are quite stable and effective, it's just the 0.x packages that are somewhat dangerous, and in some distributions this isn't true because they fix bugs independently but keep the version number the same! For example nano 0.8.6 (free pico clone) in Debian is as stable as the latest devel. releases, now a 0.9.14, but just without the other features. If you go download nano 0.8.6 from the developer, it will be full of bugs and probably will crash if you try to mark text.
If you want to find out how many Linux bugs there are in all the packages (which isn't fair anyway since MS has lots of bugs in the products that don't ship with windows) you have to keep a count of what packages are common to multiple distributions, and also unique bugs (which should probably be thrown out since they're insignificant to the OS as a whole, like a typo in the intaller). If you did this you would find surprisingly fewer bugs in Linux.
Also NT doesn't come with three mainstream text editors (vi, emacs, pico, maybe also joe, ae, etc.), two or three desktop environments still somewhat in development (GNOEM, KDE, xfce), three or four graphical shells/file managers (GNOME's, KDE's, Midnight Commander). The point is that when you give people this much choice and flexibility you increase the chance of bugs, okay. If NT gives you one of each of those and that one is buggy, there is reason to complain. In Linux, if GNOME crashes too much for you (I don't think so for the record) or is too slow, you can always switch to KDE. If vi is too cryptic, use emacs. If pine can't refresh that top blank row on the screen, use mutt.
How about a hunt the wumpus?
I did that last year in 10th grade in pascal and finished it in a week, because I enjoyed it so much. I spent the rest of the month (when everyone else was scrambling to finish) adding a god mode that let you do all sorts of quick wins, like cruise missiles, jump to any room, and infinite HP.
RedHat's basic OS strategy seems to be to release a .0 with lots of new stuff and improvements, but with it inevitably comes lots of bugs. For example 6.0 had 2.2 kernel, libc6, etc. the first distribution to do that. But it was terrible, lots of problems and bugs that I have seen on many 6.0 systems, like the mysterious "Shutting down X font server [FAILED]" and "nfsd: terminating on signal 9" messages every time to halt/reboot. The version of GNOME it came with was also really unstable.
.1 release. I was much happier with 6.1 when I quickly installed it. It worked much better but I didn't appreciate the unmaintained/undocumented text mode installer, or the fact it didn't install a kernel with kernel module loader.
.2 releases, but I presume they fix more problems, making them the most stable.
Then RedHat fixes most of these problems in a
I don't know about the
So imaging what a beta of an unstable product will be... 2.4.0-test4pre2, gcc-3.0pre5, etc.
I would stick with 6.2 unless you're really brave.
Bad analogy. It's more like:
You bought a door lock from a company. However the lock model is defective. Which is more likely to get broken into:
1. The company issues a public recall of the door lock and offers free replacement.
2. The company doesn't tell anybody, but changes it in their next model.
Another example: remember that pirranha hole in RedHat 6.2 a while back? What if RedHat didn't tell anybody, and instead just fixed it to put in 7.0, or quietly put it in the updates section? The latter possibility wouldn't even get it to all the mirrors before 7.0 came out; how is this security?
Security through obscurity has been proven not to work through practice.
We aren't disclosing holes just to the kiddies, we're disclosing it to everybody willing to listen. That means people can know when there's a problem, to which they have every right. Otherwise if one person found this hole, that information will get passed on and on until you get cracked and have no idea why. Security through obscurity is only appealing to lazy sysadmins who don't want to bother with actively keeping their system secure (by visiting bugtraq etc.) and instead want it to be done passively (Microsoft releases a new SP) This is no way to maintain a server and thus no way to look at security.
think that guy who said the G4 Cube was a hoax will do the same this time? Hope he has another hockey puck mouse to eat :-)