Why do you think this is proprietary? Don't you think that kind of limits the usefulness of such a chip? I mean what good is a digital signature or encrypted data if only people using an IBM machine with one of these chips can use/decrypt it?
I think it's a pretty safe bet they're using existing cryptographical systems. An earlier post said they were using RSA algorithms, but I haven't been able to verify that myself.
The real issue is: How secure is is to trust the identity of the user based on his CPU/board ID when someone else could so easily "pretend" to be me by sending my CPU ID all over the net?
You can't, for precisely the reason you indicate. Anyone considering this information to be an authentic ID is smoking crack.
Fortunately, this chip isn't about sending your "ID" all over the 'Net. It's about cryptography and digital signatures, which are a bit harder to forge than a simple ID.
Along the trojan/virus thread, why in the world would somebody write such a virus? The only data this chip would attempt to make available is perhaps the public encryption key, which is designed to be put out into the public anyways. I don't see the big privacy problem here. A legitimate example of a privacy-invading virus would be one that watches the system and constantly reports where the current machine is browsing, what they're doing, what documents they have, etc., but this can be done with or without a cryptography chip such as this.
I suppose a trojan could use the chip to digitally "sign" something the user didn't intend to sign, but re-read the article: a user PIN (password) is allegedly required to activate this chip. *shrug*..
This chip isn't being marketed at all as any "real" security solution. The article explicitely states this. In the event a consumer needs a more secure solution, IBM has add-ons and other products to suit them. The cryptography, they say, should be adequate for 80% of their customers. I agree.
*IF* there is a backdoor. Somehow I doubt that such a back door exists. There's always the possibility that a back door will be discovered (and it's almost a guaranteed certainty, given enough time). If one is found, IBM will be nailed with lawsuits up the ass, criminal proceedings, you name it.
It doesn't make good business sense.
You know, it's certainly possible (I mean technologically, obviously) for the government to sneak in a hidden backdoor in Microsoft Windows. Does that mean we should ban and legislate Windows into extinction? It's also possible that they've secretly placed a backdoor in the operating systems that run on our Internet's routers. Quick! Ban the Internet!
Yes, each chip has a public key. If you don't want that public key given out, don't use software that makes use of it. Period.
I occasionally make use of a software-based PGP implementation, but you don't see me scrambling to hide my public key from people.
Remember: Multi-user systems are pretty commonplace nowadays (NT, Unix, even Windows-based workstations). It makes absolutely NO sense whatsoever to suddenly convert all programs so that they use this hardware-based encryption scheme over a user-defined one.
Most people don't realize what the "color temperature" and brightness/contrast controls are really for. Most people have these adjusted at their highest (or default) values and never think to change them.
The general idea is to adjust the brightness and contrast controls so that the whitest white on your screen is no brighter than a piece of paper held up beside it, and the darkest black is the lightest black that appears "black" (i.e. as low as it'll go to the point where you can't tell the difference anymore). That gives you a full, rich contrast of brightness on par with everything else in the room.
In addition, most people will discover that the color "white" on their monitor is quite a lot bluer than a "white" piece of paper. This is due to lighting in the room and SHOULD be compensated for by taking advantage of the monitor's color temperature setting or through the use of software such as Adobe's gamma/color correction utility.
So basically, the white on your screen should match the color and brightness of a white piece of paper held up beside it.
If you change the lighting near your PC, at the very least adjust the brightness/contrast to match (that's why these controls are so accessible).
You'll find it's a LOT easier to stare at a monitor all day if it's properly configured.
People insist on taking something relatively benign and beneficial and keep "taking it to the next level" where suddenly it isn't quite so benign or beneficial, and then proceed to judge that thing based on where it can be taken.
This is totally unfair and just silly.
Hey, wow, you know, I have this friend that invented a thing called a "microphone" that can be used to detect sounds. But I'm kinda worried, because, you know, you could put this microphone someplace remote and using a bit of wire, you could hear what was going on in another room. In fact, you could really hide these in every single room in the city, and people could, like, memorize the sounds of other peoples voices and then compare it and that way they can track where everyone in the city is at any given time! THIS TECHNOLOGY MUST BE STOPPED AT ALL COSTS.
If there are people out there that wish to abuse technology such as this in the manners you suggest, fight those people, don't fight the technology. Write your government. Write businesses you suspect are considering using the technology as you suggest (I sincerely doubt any are).
The article states only wanted criminals will be temporarily added to their "face" database. If you aren't a wanted criminal, you're not even *in* the database, much less identified on sight. In the store example, only known, caught shoplifters are added. Don't shoplift (or don't get caught). If that store's policy of photographing the faces of shoplifters and comparing their face with patrons disturbs you, DON'T SHOP THERE.
All other applications of this technology that you suggest are paranoid fantasies. Stop judging something based on what it's theoretically capable of.
I can't even fathom a "big brother" hypothetical here. In the police example, only *wanted* violent criminals are added to the database. Unless you're a wanted fugitive, you have absolutely nothing to worry about. Secondly, the article states that businesses are testing this system out by adding *known* shoplifters to its database as they are caught. If you don't want to be added to their database, don't shoplift there (or don't get caught). If you're paranoid about their security cameras, don't shop there (though you'll be hard-pressed to find a store that doesn't use cameras in some fashion).
The only difference between existing stores and these testbed stores is that in existing stores, there's a human being watching the cameras, looking for familiar faces. In this case, it's the computers looking for the SAME familiar faces.
The paranoid fears that every citizen is being labeled and tracked by these systems is just utter bullshit. I sincerely wish you people would read the article before you start up with your idiotic big brother conspiracy theories that are so obviously uninformed by those of us who HAVE read the article and UNDERSTAND what's really happening.
Some of these Slashdot comments are getting pretty pathetic nowadays.
btw, I'm using swbell.net for my isp. They have _really_ good support for non-windows tcp/ip based machines (they don't even ask).
How did you get them to support you? What is your secret?
I used swbell.net for about a year and a half with my ISDN line, and had NOTHING but trouble getting any sort of help. A typical call started out like this:
Them: "Are you using Windows or Macintosh?" Me: "Neither.. I'm using a Linux system." Them: "Oh, we don't support that."
Problems ranged from an inability to authenticate (PAP auth timeouts) to an incorrect IP assignment (pppd would request 10.0.0.1, my eth0 address, and their servers would occasionally *acknowledge* that request instead of NAK'ing it and providing their own, which would be normal behavior) to major packet loss inside their network.
I never got them to acknowledge the first two problems, which started/stopped/started as they upgraded their terminal servers to various software revisions (and, for argument's sake, could quite possibly be a problem with pppd, but my instincts say otherwise). Whenever I'd call or e-mail and bring it up (complete with PPP/LCP packet traces), they would have no idea what to do with what info I'd pasted and would simply say, "Nobody else has complained of this exact problem." What they fail to realize is that under Windows, *it simply disconnects you*. You don't get a message saying "PAP authentication timed out!" Since Windows users are accustomed to links dropping randomly and machines requiring reboots all the time, it's no surprise that they don't call their ISP, and even if they do, the only information the ISP has to go on is "my modem seems to occasionally randomly disconnected right after I make the call, or at some point afterwards." I figured I was doing them a *favor* by giving them the precise PPP packets that caused the problem in the first place.
To even report packet loss I would either have to pray for a clueful tech (which happened only once, but I think it was a supervisor I got that time), or I'd have to call back and pretend to be a poor Windows sap with the same problem (naturally I'd have to dumb down my description of the problem, since Windows dialogs are much less informative than, say, a verbose pppd log), which only occasionally resulted in a quick investigation by them, which resulted in a "Oh, wow, it seems you're right. We do seem to be having problems in your area." response. Forget an e-mail with a traceroute pasted in it. I invariably get an e-mail 3 days later that says, "I have no idea what the problem is, but everything seems to be working fine on our end. Let us know if you're still having problems and we can try giving you a new init string."
You have no idea how many times I would call up and the first thing the tech would suggest is a new MODEM INITIALIZATION STRING. Remember: I'm using an ISDN line. I would clearly state this in my opening greeting.
To make matters worse, swbell.net techs apparently do not receive announcements from nor are they able to query any engineering or network staff (except *maybe* via their supervisors, which they are reluctant to do). Worst of all, they do not have access to any form of connection history or diagnostics about your dialup link. The only thing they can seem to pull up on their screen is your billing info and (what appears to be) a single text box with tech comments from previous calls. Without crucial information such as past connection histories (that describe disconnection reasons, among other things), diagnosing connection-related problems becomes *impossible*. The extent of their support for these types of things is simply a new init string.
*Pathetic* support, *especially* for Linux.
I have no problem with tech support being Windows-oriented, but I *do* have a problem with techs freaking out or just repeating,"We don't support that," when a non-OS-specific connection problem occurs and I'm not using Windows.
You'll have to pardon my rant.:) After a year and a half of this, I cancelled, and wrote them a nice long letter explaining why.
Do a search for XML at FreshMeat and test some of the implementations out. If they don't have support for the reliability mechanisms you state, request or add them yourself.
I believe most of these libraries just generate the XML text and more or less rely on the application to write it out to file, so you pretty much have as much control to be as reliable as you want.
In addition to the other poster's comment that you can use < to represent < and > to represent >, you can also simply use the "Extrans" posting method (versus "Plain Old Text"), which automatically does these conversions for you.
Someone else mentioned the likelyhood of, say, a/usr/lib/sgml-like directory where system-wide XML configuration files would be. An alternative could be/etc/sgml,/etc/xml,/etc/config, whatever.
The point is that if we establish a standard system-wide configuration path, it would be pretty easy to do what you're describing using traditional remote FS techniques.
If you wanted some apps to be remotely configured and some locally configured, create an/etc/sgml/remote and an/etc/sgml/local and update everyone's $XML_CONFIG_PATH appropriately.
Like another poster said, so long as they have a basic grasp of the XML libraries that exist, it's just a matter of calling the library's parse and write functions to read and create your own application-specific XML files.
Though learning XML would most certainly be a huge advantage, but it's hardly necessary. It's pretty easy for a non-XML-savvy person to edit an XML configuration file. It's not too difficult to figure out.
So long as a competant library exists to act as mediator between an application and an XML file, things should be fine. To the best of my knowledge, existing XML libraries do perform these tasks, and well.
XML isn't terribly difficult to represent with data structures. Thus, so long as you have valid data structures in memory, it shouldn't be much of a chore to write that out in a valid XML file.
Now, if the program poorly represents what it wants in a badly-constructed data structure, that XML, while perhaps valid XML, might not be exactly what the author intended. Unfortunately, there's not much you can do about it. A crappy programmer is a crappy programmer, and the author would probably just as easily foul up a plaintext configuration file.
So long as we're being picky, the "speed" and "effectiveness" of either approach is virtually the same. I can either reach for my mouse, click, slide, slide, click, or I reach for my keyboard, ALT-TAB my way to the open command prompt (if it's already open, otherwise, I need to open it) and type the relevant command.
In this particular instance, there's no appreciable gain either way.
From an idle state, what if you wanted to find a folder you placed in c:\ earlier that day, but you weren't quite sure of the same. What's faster? "ALT-TAB, cd \, dir" or double-click, double-click, peruse?
In many cases there is no net gain by using the command line, and in most ALL cases, there is definitely a heirarchical logic to using the graphical interface. In these cases, I'll use whatever interface I'm using at the time. If I have a directory folder open, and I need to move stuff around, I'll use that. If I'm working on a Unix-ish command-prompt and need to move a file or two around, I'll use that. It's inefficient to switch, since the gain is so marginal.
Now, that's not to say there *aren't* certain tasks where a command-line prompt will be tons faster. At the same time, though, one should concede that there are also tasks where a GUI representation of the system makes a lot more sense and can work just as well.
IMO, this is turning into yet another "GUI vs CLI" holy war, so I'm bailing out now. If you folks are die-hard CLI activists, fine, use it. Likewise with the GUI folks who just Don't Want To Learn It. I personally am of the Use-What's-Best-For-The-Task camp, the Use-What's-Efficient camp.
What makes the various Unix systems and desktop environments so great is that we're able to make that choice for ourselves. We have powerful CLI *and* GUI environments and we have people working to make each one better, instead of placing all of our efforts into just one, like Windows has.
Many people don't realize we *can* create a user desktop that's JUST as user-friendly as anything Microsoft has produced. We have the tools, the back-ends, everything we need. It's just a matter of sitting down and writing things like this kpackage utility to *do* it.
People frequently recite library version incompatibilities and things of that nature as one of the major hurdles to overcome, as there is no easy way to resolve these types of problems to the satisfaction of installed software. What they don't realize is that if you keep your system "sane" by only installing pre-packaged versions of software (like RPM's), library version dependencies are already being handled. It's just a matter of converting existing (perhaps older) source tarballs and newer software releases into RPM's (or whatever package format you prefer) so there's no *excuse* to have to do stuff by hand.
I like the idea of being shown *exactly* what an RPM installation is about to do. The whole Windows install/uninstall process always makes me nervous because I never know quite what it is that it's doing behind that "Please wait" dialog.
A true user-friendly desktop is a lot closer than people seem to think. For those that haven't performed a fresh Linux install in the past year, I'd recommend getting the latest RedHat and installing it on a play system. Experiment with KDE and Gnome. You might be surprised at the progress they've made.
They probably aren't trying to draw silly conclusions like, "Linux is unfriendly to newbies." They are probably trying to discover details about where Linux's usability is strong and where it is weak.
As I'm not a Microsoft employee, I can't really comment on *why* they're doing this study, but in the words of Jack Ryan, "It is wise to study the ways of one's adversary." They're probably doing this to see "where" Linux is in the usability department.
I would imagine information like this would be pretty important to a company like Microsoft. If I were them, I would be attempting to assess the current and potential market for a competing operating system as accurately as I possibly could. This would include comparitive usability and stability studies and predictions about where these will be in the next few years.
Every time something like this happens people invariably start posting things like "Censorship!" "Big brother!" "Slashdot sucks now!"
Yet every single time it's happened it's either been a site glitch or human error. You'd think people would figure this out?
Slashdot has always been about openness, full disclosure -- anything *but* censorship. Do you really think they would totally reverse that philosophy for an article like *this*? It really isn't even all that controversial.
They were simply hanging out in IRC chat rooms. They weren't targeting any specific person. He probably saw "her" online, initiated contact, and moved from there. The feds just sit and wait for someone to contact them. Usually they don't have to wait long.
Let's not give unnecessary credence to any more Big Brother conspiracies. Slashdot has enough of them already.:)
Are you sure about this? The print on the 1998 tax forms reads:
You are not required to provide the information requested on a form that is subject to the Paperwork Reduction Act unless the form displays a valid OMB control number.
...
If you do not file a return, do not provide the information we ask for, or provide fraudulent information, you may be charged penalties and be subject to criminal prosecution...
Form 1040 does indeed contain a valid OMB number, and this is the only reference anywhere in the IRS form documentation that mentions anything resembling "voluntary".
Is there some other place on the form or supporting documents that you're basing this information on?
If you don't have the barcode tattooed someplace stupid like the center of your forehead, you'd always have the choice to simply not show it. I don't understand why you don't think there's a choice here.
Of course, I'm hardly advocating the use of a tattooed barcode, I'm just playing devil's advocate.
If the media would quit giving so much credence and attention to packet kiddies and their l33t IRC hax0rZ groups, quite a lot of them would no longer have any reason to continue.
By constantly reporting on each "terf battle" that goes on between these groups of adolescents, the media is only *encouraging* them and other groups to do things that could merit media attention.
If the FBI were actually planning on doing the things you say, I would happily agree with you -- an expansion to wiretapping powers allowing them to monitor communications *without* a court order would most certainly be a very bad thing.
What I *don't* understand is where you're getting that. I've scoured dozens of news sites and I cannot find a single mention of the FBI considering what you're describing.
The CALEA only requires telecommunications providers to assist (and be compensated by) law enforcement in their efforts to carry out court-ordered wiretaps.
The *technology* to do what you describe has been here for years (though only with analog networks). It is, however, ILLEGAL, with or without the CALEA. The court order requirement is still in place. I guess I just don't know where it is you're getting the whole "tape/store/index" thing. Maybe I missed an earlier article or a URL or something. I simply can't imagine anything remotely like that ever being made legal. It's technologically within the FBI's capabilities to come to your home, break down your door and search your house mercilessly without getting a search warrant. That doesn't mean we should stop issuing search warrants, though.
Slashdot Mirror
Why do you think this is proprietary? Don't you think that kind of limits the usefulness of such a chip? I mean what good is a digital signature or encrypted data if only people using an IBM machine with one of these chips can use/decrypt it?
I think it's a pretty safe bet they're using existing cryptographical systems. An earlier post said they were using RSA algorithms, but I haven't been able to verify that myself.
The real issue is: How secure is is to trust the identity of the user based on his CPU/board ID when someone else could so easily "pretend" to be me by sending my CPU ID all over the net?
You can't, for precisely the reason you indicate. Anyone considering this information to be an authentic ID is smoking crack.
Fortunately, this chip isn't about sending your "ID" all over the 'Net. It's about cryptography and digital signatures, which are a bit harder to forge than a simple ID.
Along the trojan/virus thread, why in the world would somebody write such a virus? The only data this chip would attempt to make available is perhaps the public encryption key, which is designed to be put out into the public anyways. I don't see the big privacy problem here. A legitimate example of a privacy-invading virus would be one that watches the system and constantly reports where the current machine is browsing, what they're doing, what documents they have, etc., but this can be done with or without a cryptography chip such as this.
I suppose a trojan could use the chip to digitally "sign" something the user didn't intend to sign, but re-read the article: a user PIN (password) is allegedly required to activate this chip. *shrug*..
This chip isn't being marketed at all as any "real" security solution. The article explicitely states this. In the event a consumer needs a more secure solution, IBM has add-ons and other products to suit them. The cryptography, they say, should be adequate for 80% of their customers. I agree.
If there is a backdoor...
*IF* there is a backdoor. Somehow I doubt that such a back door exists. There's always the possibility that a back door will be discovered (and it's almost a guaranteed certainty, given enough time). If one is found, IBM will be nailed with lawsuits up the ass, criminal proceedings, you name it.
It doesn't make good business sense.
You know, it's certainly possible (I mean technologically, obviously) for the government to sneak in a hidden backdoor in Microsoft Windows. Does that mean we should ban and legislate Windows into extinction? It's also possible that they've secretly placed a backdoor in the operating systems that run on our Internet's routers. Quick! Ban the Internet!
Yes, each chip has a public key. If you don't want that public key given out, don't use software that makes use of it. Period.
I occasionally make use of a software-based PGP implementation, but you don't see me scrambling to hide my public key from people.
Remember: Multi-user systems are pretty commonplace nowadays (NT, Unix, even Windows-based workstations). It makes absolutely NO sense whatsoever to suddenly convert all programs so that they use this hardware-based encryption scheme over a user-defined one.
Most people don't realize what the "color temperature" and brightness/contrast controls are really for. Most people have these adjusted at their highest (or default) values and never think to change them.
The general idea is to adjust the brightness and contrast controls so that the whitest white on your screen is no brighter than a piece of paper held up beside it, and the darkest black is the lightest black that appears "black" (i.e. as low as it'll go to the point where you can't tell the difference anymore). That gives you a full, rich contrast of brightness on par with everything else in the room.
In addition, most people will discover that the color "white" on their monitor is quite a lot bluer than a "white" piece of paper. This is due to lighting in the room and SHOULD be compensated for by taking advantage of the monitor's color temperature setting or through the use of software such as Adobe's gamma/color correction utility.
So basically, the white on your screen should match the color and brightness of a white piece of paper held up beside it.
If you change the lighting near your PC, at the very least adjust the brightness/contrast to match (that's why these controls are so accessible).
You'll find it's a LOT easier to stare at a monitor all day if it's properly configured.
People insist on taking something relatively benign and beneficial and keep "taking it to the next level" where suddenly it isn't quite so benign or beneficial, and then proceed to judge that thing based on where it can be taken.
This is totally unfair and just silly.
Hey, wow, you know, I have this friend that invented a thing called a "microphone" that can be used to detect sounds. But I'm kinda worried, because, you know, you could put this microphone someplace remote and using a bit of wire, you could hear what was going on in another room. In fact, you could really hide these in every single room in the city, and people could, like, memorize the sounds of other peoples voices and then compare it and that way they can track where everyone in the city is at any given time! THIS TECHNOLOGY MUST BE STOPPED AT ALL COSTS.
If there are people out there that wish to abuse technology such as this in the manners you suggest, fight those people, don't fight the technology. Write your government. Write businesses you suspect are considering using the technology as you suggest (I sincerely doubt any are).
The article states only wanted criminals will be temporarily added to their "face" database. If you aren't a wanted criminal, you're not even *in* the database, much less identified on sight. In the store example, only known, caught shoplifters are added. Don't shoplift (or don't get caught). If that store's policy of photographing the faces of shoplifters and comparing their face with patrons disturbs you, DON'T SHOP THERE.
All other applications of this technology that you suggest are paranoid fantasies. Stop judging something based on what it's theoretically capable of.
I can't even fathom a "big brother" hypothetical here. In the police example, only *wanted* violent criminals are added to the database. Unless you're a wanted fugitive, you have absolutely nothing to worry about. Secondly, the article states that businesses are testing this system out by adding *known* shoplifters to its database as they are caught. If you don't want to be added to their database, don't shoplift there (or don't get caught). If you're paranoid about their security cameras, don't shop there (though you'll be hard-pressed to find a store that doesn't use cameras in some fashion).
The only difference between existing stores and these testbed stores is that in existing stores, there's a human being watching the cameras, looking for familiar faces. In this case, it's the computers looking for the SAME familiar faces.
The paranoid fears that every citizen is being labeled and tracked by these systems is just utter bullshit. I sincerely wish you people would read the article before you start up with your idiotic big brother conspiracy theories that are so obviously uninformed by those of us who HAVE read the article and UNDERSTAND what's really happening.
Some of these Slashdot comments are getting pretty pathetic nowadays.
btw, I'm using swbell.net for my isp. They have _really_ good support for non-windows tcp/ip based machines (they don't even ask).
:) After a year and a half of this, I cancelled, and wrote them a nice long letter explaining why.
How did you get them to support you? What is your secret?
I used swbell.net for about a year and a half with my ISDN line, and had NOTHING but trouble getting any sort of help. A typical call started out like this:
Them: "Are you using Windows or Macintosh?"
Me: "Neither.. I'm using a Linux system."
Them: "Oh, we don't support that."
Problems ranged from an inability to authenticate (PAP auth timeouts) to an incorrect IP assignment (pppd would request 10.0.0.1, my eth0 address, and their servers would occasionally *acknowledge* that request instead of NAK'ing it and providing their own, which would be normal behavior) to major packet loss inside their network.
I never got them to acknowledge the first two problems, which started/stopped/started as they upgraded their terminal servers to various software revisions (and, for argument's sake, could quite possibly be a problem with pppd, but my instincts say otherwise). Whenever I'd call or e-mail and bring it up (complete with PPP/LCP packet traces), they would have no idea what to do with what info I'd pasted and would simply say, "Nobody else has complained of this exact problem." What they fail to realize is that under Windows, *it simply disconnects you*. You don't get a message saying "PAP authentication timed out!" Since Windows users are accustomed to links dropping randomly and machines requiring reboots all the time, it's no surprise that they don't call their ISP, and even if they do, the only information the ISP has to go on is "my modem seems to occasionally randomly disconnected right after I make the call, or at some point afterwards." I figured I was doing them a *favor* by giving them the precise PPP packets that caused the problem in the first place.
To even report packet loss I would either have to pray for a clueful tech (which happened only once, but I think it was a supervisor I got that time), or I'd have to call back and pretend to be a poor Windows sap with the same problem (naturally I'd have to dumb down my description of the problem, since Windows dialogs are much less informative than, say, a verbose pppd log), which only occasionally resulted in a quick investigation by them, which resulted in a "Oh, wow, it seems you're right. We do seem to be having problems in your area." response. Forget an e-mail with a traceroute pasted in it. I invariably get an e-mail 3 days later that says, "I have no idea what the problem is, but everything seems to be working fine on our end. Let us know if you're still having problems and we can try giving you a new init string."
You have no idea how many times I would call up and the first thing the tech would suggest is a new MODEM INITIALIZATION STRING. Remember: I'm using an ISDN line. I would clearly state this in my opening greeting.
To make matters worse, swbell.net techs apparently do not receive announcements from nor are they able to query any engineering or network staff (except *maybe* via their supervisors, which they are reluctant to do). Worst of all, they do not have access to any form of connection history or diagnostics about your dialup link. The only thing they can seem to pull up on their screen is your billing info and (what appears to be) a single text box with tech comments from previous calls. Without crucial information such as past connection histories (that describe disconnection reasons, among other things), diagnosing connection-related problems becomes *impossible*. The extent of their support for these types of things is simply a new init string.
*Pathetic* support, *especially* for Linux.
I have no problem with tech support being Windows-oriented, but I *do* have a problem with techs freaking out or just repeating,"We don't support that," when a non-OS-specific connection problem occurs and I'm not using Windows.
You'll have to pardon my rant.
Don't know. I've never used them for writing XML.
Do a search for XML at FreshMeat and test some of the implementations out. If they don't have support for the reliability mechanisms you state, request or add them yourself.
I believe most of these libraries just generate the XML text and more or less rely on the application to write it out to file, so you pretty much have as much control to be as reliable as you want.
In addition to the other poster's comment that you can use < to represent < and > to represent >, you can also simply use the "Extrans" posting method (versus "Plain Old Text"), which automatically does these conversions for you.
Someone else mentioned the likelyhood of, say, a /usr/lib/sgml-like directory where system-wide XML configuration files would be. An alternative could be /etc/sgml, /etc/xml, /etc/config, whatever.
/etc/sgml/remote and an /etc/sgml/local and update everyone's $XML_CONFIG_PATH appropriately.
The point is that if we establish a standard system-wide configuration path, it would be pretty easy to do what you're describing using traditional remote FS techniques.
If you wanted some apps to be remotely configured and some locally configured, create an
Like another poster said, so long as they have a basic grasp of the XML libraries that exist, it's just a matter of calling the library's parse and write functions to read and create your own application-specific XML files.
Though learning XML would most certainly be a huge advantage, but it's hardly necessary. It's pretty easy for a non-XML-savvy person to edit an XML configuration file. It's not too difficult to figure out.
So long as a competant library exists to act as mediator between an application and an XML file, things should be fine. To the best of my knowledge, existing XML libraries do perform these tasks, and well.
XML isn't terribly difficult to represent with data structures. Thus, so long as you have valid data structures in memory, it shouldn't be much of a chore to write that out in a valid XML file.
Now, if the program poorly represents what it wants in a badly-constructed data structure, that XML, while perhaps valid XML, might not be exactly what the author intended. Unfortunately, there's not much you can do about it. A crappy programmer is a crappy programmer, and the author would probably just as easily foul up a plaintext configuration file.
A libxml already exists. In fact, most languages already have some sort of library support for XML.
The support is there, the libraries are there. It's just that there's no "config file standard" yet and developers haven't really looked into it.
I kinda vented -- Posts like that are all-too-frequent and I just picked one and responded.
So long as we're being picky, the "speed" and "effectiveness" of either approach is virtually the same. I can either reach for my mouse, click, slide, slide, click, or I reach for my keyboard, ALT-TAB my way to the open command prompt (if it's already open, otherwise, I need to open it) and type the relevant command.
In this particular instance, there's no appreciable gain either way.
From an idle state, what if you wanted to find a folder you placed in c:\ earlier that day, but you weren't quite sure of the same. What's faster? "ALT-TAB, cd \, dir" or double-click, double-click, peruse?
In many cases there is no net gain by using the command line, and in most ALL cases, there is definitely a heirarchical logic to using the graphical interface. In these cases, I'll use whatever interface I'm using at the time. If I have a directory folder open, and I need to move stuff around, I'll use that. If I'm working on a Unix-ish command-prompt and need to move a file or two around, I'll use that. It's inefficient to switch, since the gain is so marginal.
Now, that's not to say there *aren't* certain tasks where a command-line prompt will be tons faster. At the same time, though, one should concede that there are also tasks where a GUI representation of the system makes a lot more sense and can work just as well.
IMO, this is turning into yet another "GUI vs CLI" holy war, so I'm bailing out now. If you folks are die-hard CLI activists, fine, use it. Likewise with the GUI folks who just Don't Want To Learn It. I personally am of the Use-What's-Best-For-The-Task camp, the Use-What's-Efficient camp.
What makes the various Unix systems and desktop environments so great is that we're able to make that choice for ourselves. We have powerful CLI *and* GUI environments and we have people working to make each one better, instead of placing all of our efforts into just one, like Windows has.
Many people don't realize we *can* create a user desktop that's JUST as user-friendly as anything Microsoft has produced. We have the tools, the back-ends, everything we need. It's just a matter of sitting down and writing things like this kpackage utility to *do* it.
People frequently recite library version incompatibilities and things of that nature as one of the major hurdles to overcome, as there is no easy way to resolve these types of problems to the satisfaction of installed software. What they don't realize is that if you keep your system "sane" by only installing pre-packaged versions of software (like RPM's), library version dependencies are already being handled. It's just a matter of converting existing (perhaps older) source tarballs and newer software releases into RPM's (or whatever package format you prefer) so there's no *excuse* to have to do stuff by hand.
I like the idea of being shown *exactly* what an RPM installation is about to do. The whole Windows install/uninstall process always makes me nervous because I never know quite what it is that it's doing behind that "Please wait" dialog.
A true user-friendly desktop is a lot closer than people seem to think. For those that haven't performed a fresh Linux install in the past year, I'd recommend getting the latest RedHat and installing it on a play system. Experiment with KDE and Gnome. You might be surprised at the progress they've made.
They probably aren't trying to draw silly conclusions like, "Linux is unfriendly to newbies." They are probably trying to discover details about where Linux's usability is strong and where it is weak.
As I'm not a Microsoft employee, I can't really comment on *why* they're doing this study, but in the words of Jack Ryan, "It is wise to study the ways of one's adversary." They're probably doing this to see "where" Linux is in the usability department.
I would imagine information like this would be pretty important to a company like Microsoft. If I were them, I would be attempting to assess the current and potential market for a competing operating system as accurately as I possibly could. This would include comparitive usability and stability studies and predictions about where these will be in the next few years.
It's not stupid at all. It's good business sense.
Especially when I'm just typing in my password in an x-term, only to see it appear, in plain view of anyone, in some stupid text-box
:)
While I don't disagree with this annoyance, it's less of a problem for those of us that don't have to look at our fingers when we type.
Every time something like this happens people invariably start posting things like "Censorship!" "Big brother!" "Slashdot sucks now!"
Yet every single time it's happened it's either been a site glitch or human error. You'd think people would figure this out?
Slashdot has always been about openness, full disclosure -- anything *but* censorship. Do you really think they would totally reverse that philosophy for an article like *this*? It really isn't even all that controversial.
They were simply hanging out in IRC chat rooms. They weren't targeting any specific person. He probably saw "her" online, initiated contact, and moved from there. The feds just sit and wait for someone to contact them. Usually they don't have to wait long.
:)
Let's not give unnecessary credence to any more Big Brother conspiracies. Slashdot has enough of them already.
Form 1040 does indeed contain a valid OMB number, and this is the only reference anywhere in the IRS form documentation that mentions anything resembling "voluntary".
Is there some other place on the form or supporting documents that you're basing this information on?
Umm, just, like, cover it up.
Or say, "Ignore the barcode today, Sam."
If you don't have the barcode tattooed someplace stupid like the center of your forehead, you'd always have the choice to simply not show it. I don't understand why you don't think there's a choice here.
Of course, I'm hardly advocating the use of a tattooed barcode, I'm just playing devil's advocate.
If the media would quit giving so much credence and attention to packet kiddies and their l33t IRC hax0rZ groups, quite a lot of them would no longer have any reason to continue.
By constantly reporting on each "terf battle" that goes on between these groups of adolescents, the media is only *encouraging* them and other groups to do things that could merit media attention.
If the FBI were actually planning on doing the things you say, I would happily agree with you -- an expansion to wiretapping powers allowing them to monitor communications *without* a court order would most certainly be a very bad thing.
What I *don't* understand is where you're getting that. I've scoured dozens of news sites and I cannot find a single mention of the FBI considering what you're describing.
The CALEA only requires telecommunications providers to assist (and be compensated by) law enforcement in their efforts to carry out court-ordered wiretaps.
The *technology* to do what you describe has been here for years (though only with analog networks). It is, however, ILLEGAL, with or without the CALEA. The court order requirement is still in place. I guess I just don't know where it is you're getting the whole "tape/store/index" thing. Maybe I missed an earlier article or a URL or something. I simply can't imagine anything remotely like that ever being made legal. It's technologically within the FBI's capabilities to come to your home, break down your door and search your house mercilessly without getting a search warrant. That doesn't mean we should stop issuing search warrants, though.