It used to be bad with Nokia chargers, but I think at least every 3 volt phone (everything since, oh, 1997?) has compatible charger connector. There may be some problems, like my gf's new 3650 doesn't like the old car charger for 6110, not sure why (the old wall charger for 6110 works just fine, so maybe the old car charger just can't give enough power for the new phone to charge properly).
Data cables and handsfree headsets compatibility could be better though, but also that problem is going away with bluetooth, and IR has been there to replace data cables for a long time already.
Then again, are any other manufacturers any better?
Which standards do you mean that nobody conforms to? ISA? PCI? IDE? SCSI? PCMCIA? USB? ATX boards? Monitor cables? Keyboard layout?
My general impression is that such standards are adhered to rather strictly. Or at least, any product that isn't quite compatible doesn't sell / gets returned to the store, and disappears from the marketplace very very fast.
And I don't mean the technical details of what I suggested, I mean the principle of having a standard conventions for port forwarding, and standard protocols for client apps to ask for forwarding info, and for server apps to tell their host's gateway that they want port forwarding?
I mean, it could even be automatic for server apps, when an application opens an IP port for listening, OS automatically requests forwarding service from gateway (in Windows it could even ask user if he wants to give that application a port forward first time it does it, much like "personal firewalls" do now anyway). Only client apps would need either built-in support, or at least ability to set server port manually and separate app for user to ask for forwarding info.
Or do you mean it sucks just because it'd delay or prevent common use of IPv6, not because it's bad in itself? I guess I could agree with that...
I just got a thought about a solution that would not break most existing protocols or clients, while allowing new clients (supporting the protocol) to connect to servers behind NAT. See
this post of mine
. I'm no network expert really, so not sure if there are some technical probelms I don't see though... And of course it lacks the elegenace of IPv6. But it wouldn't break (most) existing software and protocols, and would not need any new infrastructure (except software upgrades in routers).
Just define a standard way (with RFC) to get standard port forwarding service from your ISP. Then design relevant protocols so that they work with port forwarding.
For example, ISP could have a (secure) web page form, where you would enter the port and the protocol you want in the computer you are. Then it assigns and tells you a new port and public IP, which gets forwarded to your IP and the port you gave in the web form. So you can put up a server running at that port, and then tell the ISP-provided port-forwarded address and port to your client users. This could include an automatic expiration time if wanted.
A more complete alternative would be to have a new protocol, with which you could ask from a router for a port forwarding info. This would be used with a scheme like above for the server side to get the port forwarding enabled. After the server owner gets port forwarding from ISP router, things could work like this:
1. give the static IP of your router and the private static NATed IP of your computer to somebody who wants to connect to you.
2. He runs the client software that supports this new query protocol, and gives it these two IPs and possibly the target port.
3. The client application queries your router with your private IP and the given port, and gets a response: "my port X is forwarded to that port at that private IP" (or "not found").
4. The Client software connect to given port at the router IP, which port forwards it to the correct port at private IP.
And note that this scheme wouldn't provide a way to ask "hey, what ports are open at that IP". So a port scanner would have to ask separately for every port at every IP he wants to scan. With increasing delay for repeated queries from same IP, port scanning for non-well-known ports would be unfeasible.
And client software (say a standard SSH client) that doesn't support new protocol but allows typing any server port would still work too. You would just need a separate query client, which would give you the forwarded port and IP of the ISP router, and then you'd have to manually enter the port for the non-supporting client.
I think you're missing the point.
You can't have connection from internet to a NATted host. You can only take connection to the NAT router. If you have control of the router, then of course you can make it do magic, but really, then you aren't behind NAT, you have the router!
I have a Linux machine at ip 192.168.75.17 at home. Please explain how can I browse the web pages on that computer from my laptop with GPRS connection, when I don't have root to any *nix server with public IP?
If your ISP supports anything except PPP with their modem pool terminal server, then get a Nokia 9xxx communicator, it offers what you want. A simple 80x25 screen and a keyboard and a wireless connection to the service provider...
ISP people, do you still support taking telnet or even SSH connection out of the terminal server of modem pool (if you can call it "terminal server" still?), or is starting PPP connection the only thing allowed for clients.
VT100 is a terminal control code standard. You can't have a "VT100" connection. So I assume you mean you want a mobile serial connection to a terminal server at ISP?
Any ISP people here, in your modem pools, can your customers do anything except start PPP connection with the terminal server of modem pool? If so, what kind, ssh or telnet?
Closest modern thing to the device you describe would be an ultralight laptop with GPRS card or a cellphone (connected to the laptop with IR/bluetooth/cable). And the article is about ditching the laptop and just having a high-end PDA-cellphone.
Of course you can make your own. Just put a modem to your linux server, then dial in from a laptop and use terminal program. Though then you can ditch GPRS-like technologies, and are forced to pay by minute instead of flat monthly fee or pay by bytes...
The reason you aren't paying more for your cable than you are is, that they don't hire well qualified people to do tech support. Or rather, most of the well qualified people would want triple the tech supporter salary before they'd even consider doing that kind of frustrating service job.
And anyway, the problem in your case was either that the one who designed the tech support database didn't do a good job, or more likely, it's extremely rare to get the thing you got, having a storm to mess up configuration. It's not the fault of the tech support person, he just follows the instructions on screen or paper and walks you through the steps. Also, considering how many times I've encountered rather baffling problems of the type "this can't possibly make that broken" on systems I've made myself, that I can't say with much conviction that the problem you described can't be a cable problem, even if it seems impossible...
The solution is clearly to have more severe economic problems in the IT industry, so there would be more top notch engineering people forced to do tech support work or starve...
Well, the Belgian littering case isn't unjust in my opinion. The driver of the car is somewhat responsible for everybody in the car. If he refuses to co-operate in finding the real quilty, then I see no wrong in giving him the fine.
And what if you add one "observer" to your 3 men in a room case, who sees which of the two survivors commits the murder. Now I think you sure can convict the "observer" for obstructing justice or whatever.
They don't want it, but some of them might read some of it, if the subject is just right. And some of these might fall for it. If it's just 1% and 1%, and you send a ten million spams, that's already 1000 successful messages.
And then of course quite a few people use filters provided by others (like ISP), since it's easy and spam is somewhat bothersome to them, but aren't still totally pissed about it and might read some.
And of course, the less spam gets through filters, the more likely it is that this "successful" spam gets read, if users mailboxes aren't filled with it. So it's competition between spammers, survival of the most evil, so to say. And I suppose also when marketting spamming services, being able to say "we know how to send mail to all AOLers" is prolly helpful...
Nice idea. But it's too late. *You* can ditch HTML mail, but that might lose you some non-spam mails. And there's no way to force everybody to ditch HTML mail.
What is to stop the spam filter "rendering" the mail as html well enough so the parts that aren't visible to the user are also stripped from the filtering. And also if most of the text is invisible to user, and/or invalid HTML, I'd say that's a good indication it's spam anyway.
1. Make them *trivial* to use with very easy syntax, so they have that specific niche (if it's not trivial to use, then the user might as well write an awk or perl one-liner, and your package wouldn't have any extra value...).
2. Make them work nicely with other traditional unix fila and text utils (tr, cut, find, xargs...). Consider what features are so important that your utils should do it themselves with simpler command syntax (perhaps like interpreting all numbers as decimal even if they have leading zeroes, so you don't have to use sed or something to remove leading zeroes from numbers), and what operations could just require using other tools and pipeing (perhaps like applying to multiple files recursively with find and xargs, instead of built-in directory recursion and wild card handling).
3. Combine them into one binary/script.
4. Do it in standard ANSI C, so it'll compile under just about anything. And use good and consistent coding practices.
The perl script collection, as your tools are now, is sure nice for your personal use, but for other people I'd say it's just a snippet library... But not useful as a stand-alone tool, as it's not worth the trouble to learn using it, and the headache of making sure you have right perl etc. Sure a nice thing to have in sourceforge or something, I'm sure quite a few people would find it useful, but it's not really anything that could get included in several linux distros.
Wouldn't that make it the publishers problem to obtain the permission? Except I do think the publisher doesn't need anybodys permission, I imagine publishers want a very broad rights to any book when publishing it...
If you want to arbitrarily categorize some of these permissions as rights,
Well, I think the there's such thing as "copyright" defined in the law. And GPL gives you more rights than copyright law does. If you don't agree with GPL, then you are limited by the copyright law and whatever other IP-related laws apply.
I don't see any kind of morality issue here (unless you think copyright law is immoral).
No. Producing food and manufacturing goods etc would disappear as a job. But creating new objects for replication would be a "new" big thing (hey, now a working prototype would be the final product as well!). Also storing objects for replication would be a new big business. Service industry would increase.
And just how do you replicate a house? A scyscraper? A power line going accross a continent?
If things would go so far that we'd have nothing we'd *need* to do, having robots/computers designing and making "original" things to be replicated and creating other robots who would be doing the manual assembly of big things, then I think not being innovative would be secondary concern compared to being completely replaced by said computers/robots...
Well, isn't this solved by a "proof of concept" prototype requirement? Perhaps retroactively, ie if owner of the patent doesn't produce the prototype within 2 years (or something), the patent expires already at that point (as well as any ongoing patent infringement lawsuits on that patent).
That kind of practice would effectively stop "desk drawer" patents filed only to try and catch somebody from patent infringement...
If somebody invents something 2nd, but still independently, and then is willing to put the effort to use the invention, he should pay somebody who invented it earlier, filed a patent, but never has any intention to use the invention?
Neither tattoos or car paint jobs are tangible discrete goods, therefore it is unreasonable to apply the same classification, or indeed the exact same legal protections to them as to discrete objects.
A digital music file is indeed a discrete, tradeable object, as kazaa and apples' music store demonstrates.
A digital music file certainly isn't a discrete object, since there can be at any given time any number of copies of it, and anybody can make identical copies of it. A digital music file is about as much a discrete object as, well, as an RFC document for instance.
I'm not sure if it's legal to take a personal copy of a CD and then sell the CD while keeping the copy. But is it legal to rip a CD into MP3s, then destroy the CD, then sell the MP3s? If it is, then can you sell only some of the MP3, or do you have to sell all of them as a bundle? Can you even keep the CD, and just sell the MP3's? (I mean, according to US law, not according to RIAA 'sue them all and let a bribed judge sort them out' opinion, of course.)
To reiterate, the effect of the DRM is to remove one of my legal rights. Staw men about tattoo's aside, the DRM is impinging on my fair use.
I'm not so sure a right of resale is such a legal right, that it must apply to a piece information itself (in this case music), and not just to the physical media the information is on (and then if there is no clearly defined physical media, there's nothing to re-sell).
Of course it could be made such, by a law which in effect grants consumers "irrevocable right to transfer both a piece of digital information (a music track, a book) and the license to use it, to another person, as a gift or by re-sale, while destroying their own copies of this piece of information". But how do you implement this technically? Outlaw DRM? Require free-of-charge service to transfer a DRM license from one person to another? This is the current situation effectivley (DRM not in use), and lo and behold, for almost all music, I have to either buy insanely expensive CD with lots of stuff i don't want, or pirate the piece I want.
Slashdot Mirror
Data cables and handsfree headsets compatibility could be better though, but also that problem is going away with bluetooth, and IR has been there to replace data cables for a long time already.
Then again, are any other manufacturers any better?
My general impression is that such standards are adhered to rather strictly. Or at least, any product that isn't quite compatible doesn't sell / gets returned to the store, and disappears from the marketplace very very fast.
Yeah, but I'm sure they've seen plenty of pictures, so comparing to that face hugger picture should be easy enough.
And I don't mean the technical details of what I suggested, I mean the principle of having a standard conventions for port forwarding, and standard protocols for client apps to ask for forwarding info, and for server apps to tell their host's gateway that they want port forwarding?
I mean, it could even be automatic for server apps, when an application opens an IP port for listening, OS automatically requests forwarding service from gateway (in Windows it could even ask user if he wants to give that application a port forward first time it does it, much like "personal firewalls" do now anyway). Only client apps would need either built-in support, or at least ability to set server port manually and separate app for user to ask for forwarding info.
Or do you mean it sucks just because it'd delay or prevent common use of IPv6, not because it's bad in itself? I guess I could agree with that...
I just got a thought about a solution that would not break most existing protocols or clients, while allowing new clients (supporting the protocol) to connect to servers behind NAT. See this post of mine . I'm no network expert really, so not sure if there are some technical probelms I don't see though... And of course it lacks the elegenace of IPv6. But it wouldn't break (most) existing software and protocols, and would not need any new infrastructure (except software upgrades in routers).
0:0:0:0:0:FFFF:10.1.2.3
can be written simply as
Of course you can use just one :: in one address, so you know how many zeroes are left out.
For example, ISP could have a (secure) web page form, where you would enter the port and the protocol you want in the computer you are. Then it assigns and tells you a new port and public IP, which gets forwarded to your IP and the port you gave in the web form. So you can put up a server running at that port, and then tell the ISP-provided port-forwarded address and port to your client users. This could include an automatic expiration time if wanted.
A more complete alternative would be to have a new protocol, with which you could ask from a router for a port forwarding info. This would be used with a scheme like above for the server side to get the port forwarding enabled. After the server owner gets port forwarding from ISP router, things could work like this:
1. give the static IP of your router and the private static NATed IP of your computer to somebody who wants to connect to you.
2. He runs the client software that supports this new query protocol, and gives it these two IPs and possibly the target port.
3. The client application queries your router with your private IP and the given port, and gets a response: "my port X is forwarded to that port at that private IP" (or "not found").
4. The Client software connect to given port at the router IP, which port forwards it to the correct port at private IP.
And note that this scheme wouldn't provide a way to ask "hey, what ports are open at that IP". So a port scanner would have to ask separately for every port at every IP he wants to scan. With increasing delay for repeated queries from same IP, port scanning for non-well-known ports would be unfeasible.
And client software (say a standard SSH client) that doesn't support new protocol but allows typing any server port would still work too. You would just need a separate query client, which would give you the forwarded port and IP of the ISP router, and then you'd have to manually enter the port for the non-supporting client.
Would it work?
I have a Linux machine at ip 192.168.75.17 at home. Please explain how can I browse the web pages on that computer from my laptop with GPRS connection, when I don't have root to any *nix server with public IP?
ISP people, do you still support taking telnet or even SSH connection out of the terminal server of modem pool (if you can call it "terminal server" still?), or is starting PPP connection the only thing allowed for clients.
Any ISP people here, in your modem pools, can your customers do anything except start PPP connection with the terminal server of modem pool? If so, what kind, ssh or telnet?
Closest modern thing to the device you describe would be an ultralight laptop with GPRS card or a cellphone (connected to the laptop with IR/bluetooth/cable). And the article is about ditching the laptop and just having a high-end PDA-cellphone.
Of course you can make your own. Just put a modem to your linux server, then dial in from a laptop and use terminal program. Though then you can ditch GPRS-like technologies, and are forced to pay by minute instead of flat monthly fee or pay by bytes...
Ewww...
"Sorry, but we don't allow monkeys in the bar." ...
Yeah, generally reviews don't spoil the contentes of the book... That wasn't a review, it was a summary.
The reason you aren't paying more for your cable than you are is, that they don't hire well qualified people to do tech support. Or rather, most of the well qualified people would want triple the tech supporter salary before they'd even consider doing that kind of frustrating service job.
And anyway, the problem in your case was either that the one who designed the tech support database didn't do a good job, or more likely, it's extremely rare to get the thing you got, having a storm to mess up configuration. It's not the fault of the tech support person, he just follows the instructions on screen or paper and walks you through the steps. Also, considering how many times I've encountered rather baffling problems of the type "this can't possibly make that broken" on systems I've made myself, that I can't say with much conviction that the problem you described can't be a cable problem, even if it seems impossible...
The solution is clearly to have more severe economic problems in the IT industry, so there would be more top notch engineering people forced to do tech support work or starve...
And what if you add one "observer" to your 3 men in a room case, who sees which of the two survivors commits the murder. Now I think you sure can convict the "observer" for obstructing justice or whatever.
And then of course quite a few people use filters provided by others (like ISP), since it's easy and spam is somewhat bothersome to them, but aren't still totally pissed about it and might read some.
And of course, the less spam gets through filters, the more likely it is that this "successful" spam gets read, if users mailboxes aren't filled with it. So it's competition between spammers, survival of the most evil, so to say. And I suppose also when marketting spamming services, being able to say "we know how to send mail to all AOLers" is prolly helpful...
Nice idea. But it's too late. *You* can ditch HTML mail, but that might lose you some non-spam mails. And there's no way to force everybody to ditch HTML mail.
What is to stop the spam filter "rendering" the mail as html well enough so the parts that aren't visible to the user are also stripped from the filtering. And also if most of the text is invisible to user, and/or invalid HTML, I'd say that's a good indication it's spam anyway.
1. Make them *trivial* to use with very easy syntax, so they have that specific niche (if it's not trivial to use, then the user might as well write an awk or perl one-liner, and your package wouldn't have any extra value...).
2. Make them work nicely with other traditional unix fila and text utils (tr, cut, find, xargs...). Consider what features are so important that your utils should do it themselves with simpler command syntax (perhaps like interpreting all numbers as decimal even if they have leading zeroes, so you don't have to use sed or something to remove leading zeroes from numbers), and what operations could just require using other tools and pipeing (perhaps like applying to multiple files recursively with find and xargs, instead of built-in directory recursion and wild card handling).
3. Combine them into one binary/script.
4. Do it in standard ANSI C, so it'll compile under just about anything. And use good and consistent coding practices.
The perl script collection, as your tools are now, is sure nice for your personal use, but for other people I'd say it's just a snippet library... But not useful as a stand-alone tool, as it's not worth the trouble to learn using it, and the headache of making sure you have right perl etc. Sure a nice thing to have in sourceforge or something, I'm sure quite a few people would find it useful, but it's not really anything that could get included in several linux distros.
Wouldn't that make it the publishers problem to obtain the permission? Except I do think the publisher doesn't need anybodys permission, I imagine publishers want a very broad rights to any book when publishing it...
Well, I think the there's such thing as "copyright" defined in the law. And GPL gives you more rights than copyright law does. If you don't agree with GPL, then you are limited by the copyright law and whatever other IP-related laws apply.
I don't see any kind of morality issue here (unless you think copyright law is immoral).
And just how do you replicate a house? A scyscraper? A power line going accross a continent?
If things would go so far that we'd have nothing we'd *need* to do, having robots/computers designing and making "original" things to be replicated and creating other robots who would be doing the manual assembly of big things, then I think not being innovative would be secondary concern compared to being completely replaced by said computers/robots...
Well, isn't this solved by a "proof of concept" prototype requirement? Perhaps retroactively, ie if owner of the patent doesn't produce the prototype within 2 years (or something), the patent expires already at that point (as well as any ongoing patent infringement lawsuits on that patent). That kind of practice would effectively stop "desk drawer" patents filed only to try and catch somebody from patent infringement...
I don't think this is fair either.
A digital music file certainly isn't a discrete object, since there can be at any given time any number of copies of it, and anybody can make identical copies of it. A digital music file is about as much a discrete object as, well, as an RFC document for instance.
I'm not sure if it's legal to take a personal copy of a CD and then sell the CD while keeping the copy. But is it legal to rip a CD into MP3s, then destroy the CD, then sell the MP3s? If it is, then can you sell only some of the MP3, or do you have to sell all of them as a bundle? Can you even keep the CD, and just sell the MP3's? (I mean, according to US law, not according to RIAA 'sue them all and let a bribed judge sort them out' opinion, of course.)
To reiterate, the effect of the DRM is to remove one of my legal rights. Staw men about tattoo's aside, the DRM is impinging on my fair use.
I'm not so sure a right of resale is such a legal right, that it must apply to a piece information itself (in this case music), and not just to the physical media the information is on (and then if there is no clearly defined physical media, there's nothing to re-sell).
Of course it could be made such, by a law which in effect grants consumers "irrevocable right to transfer both a piece of digital information (a music track, a book) and the license to use it, to another person, as a gift or by re-sale, while destroying their own copies of this piece of information". But how do you implement this technically? Outlaw DRM? Require free-of-charge service to transfer a DRM license from one person to another? This is the current situation effectivley (DRM not in use), and lo and behold, for almost all music, I have to either buy insanely expensive CD with lots of stuff i don't want, or pirate the piece I want.