Reading some of the posts following this, I'm guessing it's because there is a how_long input to the move() algorithm. Said algorithm then calculates what it can in the time given and plays with what it knows when it runs out of time. Therefore to increase the apparent "skill" of the computer the first thing to do is to increase the how_long input so that it has time to do more figuring before it is forced to make a move. This squares with what I've seen on some chess games where the options are an either/or selection: you either enter a difficulty level or a per-turn time constraint.
Hmmm. That really doesn't sound like hardware that is four years old to me. And are we talking a buildworld from scratch-- none of this stuff had ever been compiled on that machine before? For how much of the ports tree? Just for the minimal install or for X, Gnome|KDE, some major apps like GIMP or KOffice or Evolution or Mozilla?
You see where I'm going with this, of course... but compare your situation to mine. I've got one machine that I use regularly that is five years old, and therefore has a P/133 in it (it's a laptop, and it works for the things a laptop should do, there is no reason to go spending hundreds of dollars on newer hardware). That said, I disagree with our erstwhile whiner about the compile times being an issue. It won't take weeks, but it will take some effort and maybe a few days, especially if you don't have an automation tool to help you. Even so, set the larger packages to compile when you go to bed, or off to work, or whenever. And think of this as a one time investment, you won't be recompiling most of this stuff over and over.
If this distro does even half of the hard parts: knowing where to get fresh source code, downloading the code to a local repository, helping configure the build, automating the build process, then it's quite a boon. And yes, you may have to wait for some time for this stuff to compile and install, but through the magic of CVS you might not have to wait so long to upgrade parts of it. *And* you get all the benefits of compiling from source- optimizations, special./configure options you want, and more control over the whole install.
If I was anybody anywhere looking for encryption tools, I'd start with GnuPG. This way we can avoid patented algorithms and proprietary/closed source problems altogether from the git go.
Don't be stupid. Even emacs has drop-down menus, a toolbar, 3d scrollbars, and imaging capabilities. And if that's not easy enough (given how powerful the program is it can get a tad hairy), there are several text editors for KDE and Gnome that are quite a bit more like Word in the interface department.
And frankly, this whole argument is a load to begin with. The same people you insist could never learn to use Linux are the same people who all went through DOS and whatever else back when there was no Windows. And unless kids have gotten radically dumber recently, it's no harder to learn to operate a text console than a GUI. Now I might not be the best example, but I certainly learned to manipulate text files on several different text-based OS'es by the 8th grade myself. Frankly, your example is perfect-- the person at fault there is the teacher. Imagine a math teacher who said stuff like "now to find the length of the hypoteneuse take the square root of the sum of the squares of the two sides of the right triangle" to a group of fourth graders. Hint: know your audience.
Whatever. Have you actually gotten one of these BSA letters? The tone of the letters is very much the tone of someone doing extortion. In fact, they call it a "truce". I didn't know I was even at war! The BSA are hired soldiers (aka mercenaries) in this war. I got one of these letters and for the purposes of discussion I scanned it and posted it on my website. Just type 'microsoft' at the prompt. I agree if you want to use MS software (or anyone's proprietary software) you should pay the price they ask for it, but I hardly think given the threatening tone and guilty-until-proven-innocent methodology, that we users should have to watch the way we speak out in response.
And yet isn't it amazing that until very recently almost no one did anything remotely resembling desktop publishing with Word? And unless they've fixed some of these problems in newer versions: I've seen plenty of regular folks who can't work half of the fancy layout options to save their lives.
You may even take a look at the IBM NetVista X series. I just saw one of these in my local library and was blown away. Much more attractive desktop than the new iMac-- and if they've gotten one into the library, it must have been on the market for some time now. A quick gander at ibm.com indicates a lot of price similarities, too (give or take a couple hundred). What I really want to know is: when is IBM going to offer a way to *not* buy Windows on machines like this? Aren't they the $1 billion big Linux money?
I never said it was novel... where do you think I got most of the idea? Will I ever make it through the project to a release? Maybe, maybe not. Even if I did, would more than eight people use it worldwide? Who cares? As long as developers still provide source code with free licenses, I'll be happy. I only mentioned that I was working on it because I don't expect this stuff handed to be handed to me. But since everyone is throwing in their two cents on package systems, those were mine.
And in doing so I got some good feedback from a lot of people who said that a lot of systems for whatever reason don't have compilers, so build-as-you-go wouldn't work for them (although in some of those cases they are very dependent on their OS vendor, regardless of the underlying package system). So what I'll be thinking about now is how can I make sure that I'm not compiling the same package several times on different systems that are binary compatible. That's probably a big waste of CPU cycles.
And maybe it would be easier for me to learn to build.deb files or RPMs from source packages, so that I don't have to deal with any of this and go off reinventing a bunch of wheels. After all, I'm sure I could set my local web server so that it could be added to/etc/apt/sources.list. But even so, the process of building and maintaining.debs locally needs to be managed somehow.
How about formatting
You mean markup? See also: HTML, SGML, XML, TeX.
tables See also: Excel (well, not really), fixed width records, CSV, tab-delimited files, XML
graphics
See also: GIF (ok, maybe not), JPEG, PNG, BMP, PPM, or the program you actually edit the images in
password-protection
See also: yeah, sure.
spelling/grammar checking
Spelling: ooh, a dictionary grep, impress me more. Grammar: if you can't write, don't.
highlighting
What *is* that? Other than a format/markup that doesn't print in the hardcopy?
correction/collaboration
You really ignore the fact that something like CVS handles revision control a lot better than Word ever could. Does Word support versioning multiple docs as a package, branching, the notion of checkout, providing a central source for a doc, etc?
All supported by the fact that (as RMS admits) most computer users can read Word documents
Not really true if you account for the multiple versions of Word out there. Or are you telling me that Word XP documents that fully exploit the new features somehow retain that stuff in Word 97? How about the Word before that? How about Word Perfect?
The beauty of plain text with markup is that *any* text editor on any platform that understands standard character sets is going to be able to read it. Will it be able to render all the fancy markup? Maybe not. Will you be able to read and understand the document anyway? Probably.
Proprietary binary formats for information are quite often more of a hindrance than a help. The way Office components like Excel and Word are used in large companies promotes clogged hard drives and a host of other inefficiencies. And frankly, the problems I've seen coworkers have with these programs indicate to me that the format really isn't helping that much and that these programs aren't nearly as user friendly as they are often pretended to be.
Ok. But everyone and their mother can get a C compiler for OpenBSD without blinking twice. You are not accounting for the situation where you rely on precompiled binaries, but don't have a trustable source for them (or any source in some cases). In your situation, you *could* easily get by without precompiled binaries by compiling the package on one of your other systems, and copying the executables, libraries and */share files to your firewall.
Frankly, I don't see how taking the compiler off the firewall enhances it's security. If I have access to run the compiler, I probably have enough access to simply copy precompiled binaries over. In fact, that's what you were doing when you installed snort. And if I were cracking a box, I think the last thing I'd want to do is run something highly noticeable, like a compile process.
A Unix machine without a C compiler? Can you name a few popular systems that have this problem?
And can you tell me what the odds of this package system being useful to people on those platforms actually are? I don't know if you've ever worked on a non-x86 platform, but try finding even very popular software packages pre-compiled into *either* RPM or.deb packages with any degree of currency and you'll know what I'm talking about. I cannot count the number of times I would've installed a proprietary package on my Yellow Dog system, or some other complex package that I was not anxious to spend three days compiling just to try it out, but couldn't/wouldn't because no precompiled PPC packages existed or were only from sources I had no reason to trust.
So what you're saying is that they are using their position as the maker of the pre-installed OS to eliminate competition from other software vendors by making interesting features part of the OS? Aren't we normally complaining about such behavior when some other OS maker does it?
While I appreciate this work, what I really don't understand is why not work on building a tool that doesn't rely on "packages" so much as it relies on source tarballs that are independent of any packaging system.
What *I* want (and yes, I am coding this myself) is a system that only knows as much as necessary to get the package from its original source in the rawest form available. Then the system takes the package and builds/installs it using a user account set aside for the purpose of installing non-base software.
Optimally the package system will help the user write a shareable makefile of sorts and save/share that with other systems that user has and with other users. Then, once the build is done, you zip the build directory back up so that if you should need to work with them again the whole mess is handy.
At its very best the package system recognizes source sources such as tarballs via FTP and HTTP, but also CVS. And finally some hooks to external information sources (announcement lists, a central log of known changes) so that the user can be alerted to potential upgrades, bug fix releases, and security patches.
One thing I don't like about RPM/.deb/etc is that they rely way too heavily on a database of what is installed to determine what they will install next. If I don't package my "found" software using the package system, this causes RPM/dpkg to start complaining about stuff it doesn't have that I know it does.
But that's my question. Why would I use GNUstep if it doesn't fill some need? I agree that the desktop environments are a bit overloaded (although I'm currently loving Gnome, I'm just as comfortable in twm). But I know *why* I would use KDE or Gnome, because the apps-- bloated though they may be-- are killer. I haven't a similar reason to use GNUStep, that would also apply to much simpler window managers, like virtual terminals.:)
As long as their applications operate at arms length with GPL applications, or they offer source to all the GPL stuff they include, then they are fine. As soon as they rebrand KDE (which appeared to be their base desktop environment) and don't offer source code, they run afoul of the GPL. If they want the GNU/Linux community on their side, they won't do the latter.
But the key is the installer and the apps which make this package a value (namely the Windows compatibility stuff)-- the parts they are writing themselves. As long as they don't GPL that stuff, then without the source code to any GPL apps they change their system is mostly useless to the rest of us. Thankfully, they are bound to release their changes to the source for GPL apps. Which means that if even the rest of us don't want to use the rest of their system, someone who buys just one copy of Lindows can share all the changes to the GPL bits with the community (and most importantly the original developers).
The real problem is knowing when they used Free packages. But given that they are likely to compile with the same compilers the rest of us have, the resulting executables of packages sharing common code should have some parts that are similar. Am I making any sense?
Don't be ridiculous. Both KDE and Gnome allow a very high level of customizability with respect to icon size. Now I suppose they could come with the huge buttons turned on, but many of us think their choice of "medium" is already a bit large.
The original question stands: what the heck software is written for GNUStep that makes this compelling? With KDE's Konqueror, KMail, and KOffice suite, I sure know why a lot of people would choose that system. With Gnome's Galeon, Gnumeric, and Evolution, I sure know why a lot of other people would choose that system. But why GNUStep?
And personally, I hate using Netscape because of those unmodifiable large icons. They hog space on an already crowded screen.
And I know what you mean about the edge of screen stuff. The Gnome panel kicks butt there, similar to the Mac toolbar (or whatever they call the monstrosity in their new OS) that way. Not like yer average Windows Start panel.
I didn't say I thought an image was a good thing, just that it's something I'm used to. I associate being fingerprinted with being investigated for criminal offense.
I am also concerned that they will take the raw data from a fingerprint or retinal scan and put that right on the card or in the database. Which means that it will be trivially stolen in the very near future. I think it would be relatively easy to use such data to make etched replicas of other people's fingerprints. Now if they don't store the digital data itself but a good solid hash (a la SHA1) such that only my fingerprint can produce that result, then I'd at least feel a *little* safer.
More likely I'm just paranoid. Personally I think the whole argument is backwards. We should not be fighting for the right to privacy. We should actually be fighting against the unjust laws we'd like to keep secrets because of.
Who is this "we"? Certainly not the Slashdot community. The average Slashbot *loves* DVDs and can't wait to rush out and buy LotR and Star Wars on DVD as soon as they hit the shelves, never mind that they are financing the loss of freedom they're going to come back here and whine about tomorrow.
Okay. I could be wrong and it's not a seat license. But I don't think "$100 for a single user" is very clear.
As for a "serious contender to Bill". We've had Apple running MS Office for years and years and years (and I remember writing training manuals for MS Works on Mac back in 1988). Apple has also run your basic internet stuff, your Quicken, your AOL, your high-end graphics tools, and a whole boatload of other convincing reasons to have never gotten onto Windows in the first place... but it never stuck. Plus they had what many consider to be superior engineering in the hardware side. So I don't get why Windows dominated then, and I have doubts about the likelihood that Lindows will reach its goal of being a serious contender for the MS desktop market.
The Department of Transportation, acting on instructions from Congress, has begun work with states to develop electronically smarter drivers' licenses that can be checked for validity across the country, and that have more than just than that always-awful picture â" like a fingerprint or retinal-scan imprint â" to match the card to its holder.
The part you missed: they are not simply going to connect existing systems as-is. They are planning to work with states to have "smarter" IDs. Frankly, I don't mind having my picture taken for the card, but a fingerprint or a retinal scan? Yer effing kidding right? How does this compare to ID card systems outside the USA, anyone know?
You missed nothing. They intend to throw a bunch of proprietary stuff on top of Linux (namely the Windows compatibility stuff and the installers) to make sure that you end up paying a $100/seat license for this. I don't know whether to cheer or jeer myself.
I guess I'll wait to hear whether they contribute money or code back to all the Free Software and Open Source projects they'll be taking advantage of in the process. I suppose they can't de-GPL anything, so that's a major plus.
The real question is, why for $100 would anyone switch off Windows for less than 100% compatibility with their Windows software? What guarantee will Lindows make that the next upgrade set from MS won't break Lindows, leaving users in the lurch with applications going stale?
Real Men download tarballs using FTP and figure out their own damn config options and find needed patches by scouring old Usenet postings, mailing list archives, and Magic 8 Balls.
After failing to enjoy either RPM or.deb very much I did try FreeBSD because of ports (well, plus wanting to just try it out for a while anyhow), and I found there was too much other stuff that got in my way (mostly culture shock I'm sure).
Now I'm tinkering with how I might get my own rudimentary ports system up and running as a way of extending a very basic install of a system like Debian, rather than simply managing package downloads, patching, configure options, build processes, and installation stuff all by hand. If I do it on one machine. I should be able to automate it on a second machine.
Slashdot Mirror
Reading some of the posts following this, I'm guessing it's because there is a how_long input to the move() algorithm. Said algorithm then calculates what it can in the time given and plays with what it knows when it runs out of time. Therefore to increase the apparent "skill" of the computer the first thing to do is to increase the how_long input so that it has time to do more figuring before it is forced to make a move. This squares with what I've seen on some chess games where the options are an either/or selection: you either enter a difficulty level or a per-turn time constraint.
Hmmm. That really doesn't sound like hardware that is four years old to me. And are we talking a buildworld from scratch-- none of this stuff had ever been compiled on that machine before? For how much of the ports tree? Just for the minimal install or for X, Gnome|KDE, some major apps like GIMP or KOffice or Evolution or Mozilla?
./configure options you want, and more control over the whole install.
You see where I'm going with this, of course... but compare your situation to mine. I've got one machine that I use regularly that is five years old, and therefore has a P/133 in it (it's a laptop, and it works for the things a laptop should do, there is no reason to go spending hundreds of dollars on newer hardware). That said, I disagree with our erstwhile whiner about the compile times being an issue. It won't take weeks, but it will take some effort and maybe a few days, especially if you don't have an automation tool to help you. Even so, set the larger packages to compile when you go to bed, or off to work, or whenever. And think of this as a one time investment, you won't be recompiling most of this stuff over and over.
If this distro does even half of the hard parts: knowing where to get fresh source code, downloading the code to a local repository, helping configure the build, automating the build process, then it's quite a boon. And yes, you may have to wait for some time for this stuff to compile and install, but through the magic of CVS you might not have to wait so long to upgrade parts of it. *And* you get all the benefits of compiling from source- optimizations, special
If I was anybody anywhere looking for encryption tools, I'd start with GnuPG. This way we can avoid patented algorithms and proprietary/closed source problems altogether from the git go.
Don't be stupid. Even emacs has drop-down menus, a toolbar, 3d scrollbars, and imaging capabilities. And if that's not easy enough (given how powerful the program is it can get a tad hairy), there are several text editors for KDE and Gnome that are quite a bit more like Word in the interface department.
And frankly, this whole argument is a load to begin with. The same people you insist could never learn to use Linux are the same people who all went through DOS and whatever else back when there was no Windows. And unless kids have gotten radically dumber recently, it's no harder to learn to operate a text console than a GUI. Now I might not be the best example, but I certainly learned to manipulate text files on several different text-based OS'es by the 8th grade myself. Frankly, your example is perfect-- the person at fault there is the teacher. Imagine a math teacher who said stuff like "now to find the length of the hypoteneuse take the square root of the sum of the squares of the two sides of the right triangle" to a group of fourth graders. Hint: know your audience.
Whatever. Have you actually gotten one of these BSA letters? The tone of the letters is very much the tone of someone doing extortion. In fact, they call it a "truce". I didn't know I was even at war! The BSA are hired soldiers (aka mercenaries) in this war. I got one of these letters and for the purposes of discussion I scanned it and posted it on my website. Just type 'microsoft' at the prompt. I agree if you want to use MS software (or anyone's proprietary software) you should pay the price they ask for it, but I hardly think given the threatening tone and guilty-until-proven-innocent methodology, that we users should have to watch the way we speak out in response.
And yet isn't it amazing that until very recently almost no one did anything remotely resembling desktop publishing with Word? And unless they've fixed some of these problems in newer versions: I've seen plenty of regular folks who can't work half of the fancy layout options to save their lives.
You may even take a look at the IBM NetVista X series. I just saw one of these in my local library and was blown away. Much more attractive desktop than the new iMac-- and if they've gotten one into the library, it must have been on the market for some time now. A quick gander at ibm.com indicates a lot of price similarities, too (give or take a couple hundred). What I really want to know is: when is IBM going to offer a way to *not* buy Windows on machines like this? Aren't they the $1 billion big Linux money?
I never said it was novel... where do you think I got most of the idea? Will I ever make it through the project to a release? Maybe, maybe not. Even if I did, would more than eight people use it worldwide? Who cares? As long as developers still provide source code with free licenses, I'll be happy. I only mentioned that I was working on it because I don't expect this stuff handed to be handed to me. But since everyone is throwing in their two cents on package systems, those were mine.
.deb files or RPMs from source packages, so that I don't have to deal with any of this and go off reinventing a bunch of wheels. After all, I'm sure I could set my local web server so that it could be added to /etc/apt/sources.list. But even so, the process of building and maintaining .debs locally needs to be managed somehow.
And in doing so I got some good feedback from a lot of people who said that a lot of systems for whatever reason don't have compilers, so build-as-you-go wouldn't work for them (although in some of those cases they are very dependent on their OS vendor, regardless of the underlying package system). So what I'll be thinking about now is how can I make sure that I'm not compiling the same package several times on different systems that are binary compatible. That's probably a big waste of CPU cycles.
And maybe it would be easier for me to learn to build
Except that usually source packages can be gotten from a trusted source (i.e. the developer or an authorized/official mirror).
How about formatting
You mean markup? See also: HTML, SGML, XML, TeX.
tables
See also: Excel (well, not really), fixed width records, CSV, tab-delimited files, XML
graphics
See also: GIF (ok, maybe not), JPEG, PNG, BMP, PPM, or the program you actually edit the images in
password-protection
See also: yeah, sure.
spelling/grammar checking
Spelling: ooh, a dictionary grep, impress me more. Grammar: if you can't write, don't.
highlighting
What *is* that? Other than a format/markup that doesn't print in the hardcopy?
correction/collaboration
You really ignore the fact that something like CVS handles revision control a lot better than Word ever could. Does Word support versioning multiple docs as a package, branching, the notion of checkout, providing a central source for a doc, etc?
All supported by the fact that (as RMS admits) most computer users can read Word documents
Not really true if you account for the multiple versions of Word out there. Or are you telling me that Word XP documents that fully exploit the new features somehow retain that stuff in Word 97? How about the Word before that? How about Word Perfect?
The beauty of plain text with markup is that *any* text editor on any platform that understands standard character sets is going to be able to read it. Will it be able to render all the fancy markup? Maybe not. Will you be able to read and understand the document anyway? Probably.
Proprietary binary formats for information are quite often more of a hindrance than a help. The way Office components like Excel and Word are used in large companies promotes clogged hard drives and a host of other inefficiencies. And frankly, the problems I've seen coworkers have with these programs indicate to me that the format really isn't helping that much and that these programs aren't nearly as user friendly as they are often pretended to be.
Ok. But everyone and their mother can get a C compiler for OpenBSD without blinking twice. You are not accounting for the situation where you rely on precompiled binaries, but don't have a trustable source for them (or any source in some cases). In your situation, you *could* easily get by without precompiled binaries by compiling the package on one of your other systems, and copying the executables, libraries and */share files to your firewall.
Frankly, I don't see how taking the compiler off the firewall enhances it's security. If I have access to run the compiler, I probably have enough access to simply copy precompiled binaries over. In fact, that's what you were doing when you installed snort. And if I were cracking a box, I think the last thing I'd want to do is run something highly noticeable, like a compile process.
A Unix machine without a C compiler? Can you name a few popular systems that have this problem?
.deb packages with any degree of currency and you'll know what I'm talking about. I cannot count the number of times I would've installed a proprietary package on my Yellow Dog system, or some other complex package that I was not anxious to spend three days compiling just to try it out, but couldn't/wouldn't because no precompiled PPC packages existed or were only from sources I had no reason to trust.
And can you tell me what the odds of this package system being useful to people on those platforms actually are? I don't know if you've ever worked on a non-x86 platform, but try finding even very popular software packages pre-compiled into *either* RPM or
So what you're saying is that they are using their position as the maker of the pre-installed OS to eliminate competition from other software vendors by making interesting features part of the OS? Aren't we normally complaining about such behavior when some other OS maker does it?
While I appreciate this work, what I really don't understand is why not work on building a tool that doesn't rely on "packages" so much as it relies on source tarballs that are independent of any packaging system.
What *I* want (and yes, I am coding this myself) is a system that only knows as much as necessary to get the package from its original source in the rawest form available. Then the system takes the package and builds/installs it using a user account set aside for the purpose of installing non-base software.
Optimally the package system will help the user write a shareable makefile of sorts and save/share that with other systems that user has and with other users. Then, once the build is done, you zip the build directory back up so that if you should need to work with them again the whole mess is handy.
At its very best the package system recognizes source sources such as tarballs via FTP and HTTP, but also CVS. And finally some hooks to external information sources (announcement lists, a central log of known changes) so that the user can be alerted to potential upgrades, bug fix releases, and security patches.
One thing I don't like about RPM/.deb/etc is that they rely way too heavily on a database of what is installed to determine what they will install next. If I don't package my "found" software using the package system, this causes RPM/dpkg to start complaining about stuff it doesn't have that I know it does.
But that's my question. Why would I use GNUstep if it doesn't fill some need? I agree that the desktop environments are a bit overloaded (although I'm currently loving Gnome, I'm just as comfortable in twm). But I know *why* I would use KDE or Gnome, because the apps-- bloated though they may be-- are killer. I haven't a similar reason to use GNUStep, that would also apply to much simpler window managers, like virtual terminals. :)
As long as their applications operate at arms length with GPL applications, or they offer source to all the GPL stuff they include, then they are fine. As soon as they rebrand KDE (which appeared to be their base desktop environment) and don't offer source code, they run afoul of the GPL. If they want the GNU/Linux community on their side, they won't do the latter.
But the key is the installer and the apps which make this package a value (namely the Windows compatibility stuff)-- the parts they are writing themselves. As long as they don't GPL that stuff, then without the source code to any GPL apps they change their system is mostly useless to the rest of us. Thankfully, they are bound to release their changes to the source for GPL apps. Which means that if even the rest of us don't want to use the rest of their system, someone who buys just one copy of Lindows can share all the changes to the GPL bits with the community (and most importantly the original developers).
The real problem is knowing when they used Free packages. But given that they are likely to compile with the same compilers the rest of us have, the resulting executables of packages sharing common code should have some parts that are similar. Am I making any sense?
Don't be ridiculous. Both KDE and Gnome allow a very high level of customizability with respect to icon size. Now I suppose they could come with the huge buttons turned on, but many of us think their choice of "medium" is already a bit large.
The original question stands: what the heck software is written for GNUStep that makes this compelling? With KDE's Konqueror, KMail, and KOffice suite, I sure know why a lot of people would choose that system. With Gnome's Galeon, Gnumeric, and Evolution, I sure know why a lot of other people would choose that system. But why GNUStep?
And personally, I hate using Netscape because of those unmodifiable large icons. They hog space on an already crowded screen.
And I know what you mean about the edge of screen stuff. The Gnome panel kicks butt there, similar to the Mac toolbar (or whatever they call the monstrosity in their new OS) that way. Not like yer average Windows Start panel.
I didn't say I thought an image was a good thing, just that it's something I'm used to. I associate being fingerprinted with being investigated for criminal offense.
I am also concerned that they will take the raw data from a fingerprint or retinal scan and put that right on the card or in the database. Which means that it will be trivially stolen in the very near future. I think it would be relatively easy to use such data to make etched replicas of other people's fingerprints. Now if they don't store the digital data itself but a good solid hash (a la SHA1) such that only my fingerprint can produce that result, then I'd at least feel a *little* safer.
More likely I'm just paranoid. Personally I think the whole argument is backwards. We should not be fighting for the right to privacy. We should actually be fighting against the unjust laws we'd like to keep secrets because of.
Who is this "we"? Certainly not the Slashdot community. The average Slashbot *loves* DVDs and can't wait to rush out and buy LotR and Star Wars on DVD as soon as they hit the shelves, never mind that they are financing the loss of freedom they're going to come back here and whine about tomorrow.
Okay. I could be wrong and it's not a seat license. But I don't think "$100 for a single user" is very clear.
As for a "serious contender to Bill". We've had Apple running MS Office for years and years and years (and I remember writing training manuals for MS Works on Mac back in 1988). Apple has also run your basic internet stuff, your Quicken, your AOL, your high-end graphics tools, and a whole boatload of other convincing reasons to have never gotten onto Windows in the first place... but it never stuck. Plus they had what many consider to be superior engineering in the hardware side. So I don't get why Windows dominated then, and I have doubts about the likelihood that Lindows will reach its goal of being a serious contender for the MS desktop market.
Yeah, I later noticed that the article states that Georgia already has fingerprint on license too. How the heck did this pass in CA?
The Department of Transportation, acting on instructions from Congress, has begun work with states to develop electronically smarter drivers' licenses that can be checked for validity across the country, and that have more than just than that always-awful picture â" like a fingerprint or retinal-scan imprint â" to match the card to its holder.
The part you missed: they are not simply going to connect existing systems as-is. They are planning to work with states to have "smarter" IDs. Frankly, I don't mind having my picture taken for the card, but a fingerprint or a retinal scan? Yer effing kidding right? How does this compare to ID card systems outside the USA, anyone know?
You missed nothing. They intend to throw a bunch of proprietary stuff on top of Linux (namely the Windows compatibility stuff and the installers) to make sure that you end up paying a $100/seat license for this. I don't know whether to cheer or jeer myself.
I guess I'll wait to hear whether they contribute money or code back to all the Free Software and Open Source projects they'll be taking advantage of in the process. I suppose they can't de-GPL anything, so that's a major plus.
The real question is, why for $100 would anyone switch off Windows for less than 100% compatibility with their Windows software? What guarantee will Lindows make that the next upgrade set from MS won't break Lindows, leaving users in the lurch with applications going stale?
I think the best part is that it was their own lame software that caused this to be so apparent.
Ports is for weenies. :P
.deb very much I did try FreeBSD because of ports (well, plus wanting to just try it out for a while anyhow), and I found there was too much other stuff that got in my way (mostly culture shock I'm sure).
Real Men download tarballs using FTP and figure out their own damn config options and find needed patches by scouring old Usenet postings, mailing list archives, and Magic 8 Balls.
After failing to enjoy either RPM or
Now I'm tinkering with how I might get my own rudimentary ports system up and running as a way of extending a very basic install of a system like Debian, rather than simply managing package downloads, patching, configure options, build processes, and installation stuff all by hand. If I do it on one machine. I should be able to automate it on a second machine.