If the IP of the host the connection originated from...
I think what we have here is an issue of perspective...
The connection "originates" from the machine named 'smtp' and goes thru the firewall named 'charon'... which is running an SMTP proxy.
The firewall, being an SMTP proxy, actually makes the connection to the receiving SMTP server... so... that machine won't know anything about 'smtp' other than the fact that the headers say the message originated from 'smtp'. (and the MX record is set to 'smtp' also) So, to those machines the connection will "originate" with 'charon', not 'smtp'.
The headers look something like this when they get to the next machine:
Received: from smtp.some.domain (charon.some.domain [999.999.999.999]) by who.ever.com
You can clearly see from the header that the machine purports to be 'smtp' but resolves to 'charon' and if you did a dns lookup on smtp you would see that its IP address is different from 'charon'.
So... It sounds like we would need to add 'charon' to the list of machines that can send email.
My real question is whether the message saying it comes from 'smtp' is going to cause problems when the connection is actually established with 'charon'.
So... if you have a firewall with an SMTP proxy on it... do you need to add it's address to the list of "official" senders?
All outgoing SMTP traffic appear to come from the IP address of the firewall, but... it does NOT touch the envelope or change *ANY* header info... which point to the address of the real SMTP server.
I do see almost every interpretation here so far as being wrong... so, maybe that is why it looks weak?
Search for other posts by me in this thread to see what I think the correct interpretation is...
Or, better yet... look at claim # 1 closely.
The second line goes like this:
responsive to an identification of software already installed on the user station, presenting a directory of software available for installation on the user station and not already installed on the user station
Which means that the list of software available, as returned by the server, is directly related to the software currently installed.
In other words... the list is customized for that particular client.
This is exactly what MS and Apple do for their latest OSes... and nothing like what Linux distros do.
With a Linux distro, the update server returns the same list to every client... namely, the list of all available software, even if already installed. The program on the client side slices and dices the info returned by the server to make it relevant for the client.
With this patent, the slicing and dicing are done before the data is returned to the client... and, integral to the process is the fact that the client uploads to the server a list of installed software. Again, something that doesn't happen with Linux distros.
But, something that probably is patentable. The real issue is going to be prior art.
With all of the issues of privacy... I'm not sure when it became "acceptable" for the client to upload the data required for this patent.
I've not read the patent (well, this *is*/.), but assuming that there's nothing OS-specific in it, this would apply to just about any GUIfied automatic update tool...
I have read the patent, but... IANAL.
So, that makes us pretty much even.
;-)
That being said, the patent involves much more than a GUI. The GUI isn't really the important part either.
Claim #1 specifies that the client computer provides the update server with a list of installed software and that the list of available updates is based upon this list.
MS and Apple both do this with their latest OSes.
I don't know of any Linux distro that does (I have a life). I'm certain that debian does NOT do this. And Mandrake didn't do it prior to v10... I haven't used it since 9.2 so I can't say what they do now.
What Linux systems typically do is get a list of all available software from the server. The server does not know what is installed on the client, and this is the crux of the patent.
It is the client on a Linux system that determines what is an update... not the server.
This patent seems to cover the situation where the list of available updates is determined by the server based upon the software installed on the client.
With MS and Apple systems your computer sends a list of software (and versions) that is installed and the update server sends back a list that is customized for that particular machine based on what is currently installed.
Note that the update server gets to know what you have installed, and it decides what updates you will be presented with for installation.
Linux based solutions give you a bit more privacy by not insisting that they know what you have installed. Instead, they present you with a list of everything available, even if it is already installed.
The client software does the hard work of presenting the information in a relevant manner... and deciding what is an "update" vs. "new software", etc.
Wholly different from the patent claims.
BTW, I should not have to say this... but... IANAL... YMMV... Void Where Prohibited... These statements have not been evaluated by the FDA... etc...
Does it send a list of software installed on your system to RedHat?
And, then... does the RedHat server send a customized list of software based on the uploaded list back down?
That is my reading of claim # 1 of the patent.
And, both MS and Apple update do just this very thing.
I've not used RedHat since 6.0... but, I am familiar with Mandrake and Debian update systems. And, while IANAL, I don't see them in violation of at least claim # 1.
These systems send a generic list of available software to any computer requesting the list... and the client determines what to download.
Never is a list of installed software sent to the "update server".
My original points in this thread were concerning development of web applications for a company intranet.
The company decides on the browser requirements for its employees... including turning JavaScript on (or off).
If you are saying you can't do your job (use the intranet software) because you have disabled JavaScript (even tho the company policy is to enable it)... then you can explain the problem on your way out the door.
It isn't a personal decision in the context of employeement.
It is perfectly possible to use Javascript without making your website dependent upon it. Javascript was designed that way. Stop with the straw man arguments, nobody is suggesting a ban on Javascript.
Well, my point wasn't about "pushing" JavaScript.
My point was about using JavaScript to detect old and outdated browsers.
Someone else brought up the "but I don't have JavaScript enabled" blather.
That isn't my problem. If you don't want to meet the minimum requirements to use my site, then go away. It is my site (or the site of the person paying me) and the user is not part of the decision making process.
Options are weighed, decisions are made. Get over it.
Next, someone will say requiring a browser is "asking too much".
Not only that, but you are missing the point. The point is that JavaScript is REQUIRED as a design consideration. ON PURPOSE.
Yep, that is right. Someone is purposely making a decision to do something you (apparently) don't like... probably even something you or "they" consider to be a "bad" decision. I'm sure it won't be the last time that happens.
I'm not trying to make JavaScript optional, that isn't a goal. The goal is exactly the opposite. Anything that doesn't meet that goal, is failure.
If an employer here told an employee that they shouldn't use an intranet application because they are disabled, they'd be on the wrong end of a lawsuit very quickly.
Then don't say it is "because they are disabled". If that is the real reason, then there is a problem. And there should be trouble.
But, every job has skill requirements. And, the poeple doing the job should meet those requirements. People are not one to one interchangeable. So, every tool can not possibly be usable by every person.
That is life.
My point wasn't about "getting around" some accessibility law... it was about designing the tool for the people that are going to be doing the job. In the cases I've worked on to date, that meant people without disabilities.
The software designed by a company for it's EMPLOYEES should meet the needs of those people, not some imagined person that isn't there at the time and may never be. If none of them are disabled, then why should the product take into consideration a non-existant disability?
Next you would want to force Santa to have all of the tools in his workshop usable by "normal" sized people... even tho none of the workers are "normal" sized... and couldn't handle tools of that size to boot.
No browser supports getElementById() when they have Javascript switched off.
True.
But, I've yet to come across anyone that wants to pay to create a web *application* that is not also interested in some dynamic action.
It may be as simple as wanting to select all check boxes at once... or deselect them all at once.
This will either require JavaScript, Java, ActiveX... or some other technology above and beyond plain old HTML.
JavaScript is by far (IMHO) the least "bad" of the options. (For various definitions of "bad")
And, these applications are always (so far) inside the firewall (on the intranet) where the company can explicitly control what browser(s) will be used.
And, you can get around "accessibility requirements" by not requiring anyone with a disability to use the application.
Companies do it all the time. Most of them are in such a bind to get *something* up and running... that accessibility is way down on the list.
The computers will most likely have a non-routable IP address assigned, and all of them will show up w/ the IP address of the firewall.
Even if they note the number of individual computers connecting w/ that license... there are so many "spares" and "rebuilds" in the corporate environment to make tracking a fruitless proposition.
Sure, but if the ratio is that much of a problem, then you are already into the "huge" catagory...
Just to be clear, the "problem" isn't the ratio... the ratio is close to "ideal" according to somepeople. The problem is that "average" people are not "ideal"... so, finding clothing is not easy if you are fit and closer to "ideal" than "average"... because the clothing is designed for the "average" person.
(man... that is a sh*tload of quotes...)
I hit that problem at 205 lbs... I didn't consider that "huge", even tho it was more muscular than virtually everyone I met (outside of the gym).
A normal suit is designed for an "8 inch drop" where the waist is 8 inches smaller than the chest. My chest was 46" and the waist was 32". The legs were even futher from "normal" because even the majority of gym rats don't work their lower body that much.
To me, "huge" is 280 lbs of raw muscle. Consider that Arnold's chest was 54" across... 46" is not close to the same category. Eight inches is a lot of beef in the chest area.
Anyways... I guess it is all a matter of perspective.
Slashdot Mirror
Hm...
Am I the only one that runs Drive Image (or a similar tool) before running anything from MS Update?
Always.
I've had the thing crap out too damn many times to even consider updating w/o an image backup first.
I think what we have here is an issue of perspective...
The connection "originates" from the machine named 'smtp' and goes thru the firewall named 'charon'... which is running an SMTP proxy.
The firewall, being an SMTP proxy, actually makes the connection to the receiving SMTP server... so... that machine won't know anything about 'smtp' other than the fact that the headers say the message originated from 'smtp'. (and the MX record is set to 'smtp' also) So, to those machines the connection will "originate" with 'charon', not 'smtp'.
The headers look something like this when they get to the next machine:You can clearly see from the header that the machine purports to be 'smtp' but resolves to 'charon' and if you did a dns lookup on smtp you would see that its IP address is different from 'charon'.
So... It sounds like we would need to add 'charon' to the list of machines that can send email.
My real question is whether the message saying it comes from 'smtp' is going to cause problems when the connection is actually established with 'charon'.
Given a tall enough building, a pig could stay "aloft" longer than the Wright brothers...
But, I still wouldn't call it flying.
So... if you have a firewall with an SMTP proxy on it... do you need to add it's address to the list of "official" senders?
All outgoing SMTP traffic appear to come from the IP address of the firewall, but... it does NOT touch the envelope or change *ANY* header info... which point to the address of the real SMTP server.
It seems to me that this might break.
I don't see the patent as being weak.
I do see almost every interpretation here so far as being wrong... so, maybe that is why it looks weak?
Search for other posts by me in this thread to see what I think the correct interpretation is...
Or, better yet... look at claim # 1 closely.
The second line goes like this:
responsive to an identification of software already installed on the user station, presenting a directory of software available for installation on the user station and not already installed on the user station
Which means that the list of software available, as returned by the server, is directly related to the software currently installed.
In other words... the list is customized for that particular client.
This is exactly what MS and Apple do for their latest OSes... and nothing like what Linux distros do.
With a Linux distro, the update server returns the same list to every client... namely, the list of all available software, even if already installed. The program on the client side slices and dices the info returned by the server to make it relevant for the client.
With this patent, the slicing and dicing are done before the data is returned to the client... and, integral to the process is the fact that the client uploads to the server a list of installed software. Again, something that doesn't happen with Linux distros.
But, something that probably is patentable. The real issue is going to be prior art.
With all of the issues of privacy... I'm not sure when it became "acceptable" for the client to upload the data required for this patent.
I've not read the patent (well, this *is* /.), but assuming that there's nothing OS-specific in it, this would apply to just about any GUIfied automatic update tool...
I have read the patent, but... IANAL.
So, that makes us pretty much even.
;-)
That being said, the patent involves much more than a GUI. The GUI isn't really the important part either.
Claim #1 specifies that the client computer provides the update server with a list of installed software and that the list of available updates is based upon this list.
MS and Apple both do this with their latest OSes.
I don't know of any Linux distro that does (I have a life). I'm certain that debian does NOT do this. And Mandrake didn't do it prior to v10... I haven't used it since 9.2 so I can't say what they do now.
What Linux systems typically do is get a list of all available software from the server. The server does not know what is installed on the client, and this is the crux of the patent.
It is the client on a Linux system that determines what is an update... not the server.
This patent seems to cover the situation where the list of available updates is determined by the server based upon the software installed on the client.
Yes, it is different.
With MS and Apple systems your computer sends a list of software (and versions) that is installed and the update server sends back a list that is customized for that particular machine based on what is currently installed.
Note that the update server gets to know what you have installed, and it decides what updates you will be presented with for installation.
Linux based solutions give you a bit more privacy by not insisting that they know what you have installed. Instead, they present you with a list of everything available, even if it is already installed.
The client software does the hard work of presenting the information in a relevant manner... and deciding what is an "update" vs. "new software", etc.
Wholly different from the patent claims.
BTW, I should not have to say this... but... IANAL... YMMV... Void Where Prohibited... These statements have not been evaluated by the FDA... etc...
The debian based tools don't send a list of installed software to the upload server.
This seems to be an integral requirement of claim # 1.
The update server (in the patent) provides a customized list of updates specific to the client it is communicating with.
The debian tools simply retrieve a list of all available software (and version numbers) and the software on the client determines what is relevant.
Never is a list of installed software sent as a part of the upgrade process.
This patent requires the update server knowing what is installed on the client machine.
Linux systems work the other way around... knowing what is available.
Does it send a list of software installed on your system to RedHat?
And, then... does the RedHat server send a customized list of software based on the uploaded list back down?
That is my reading of claim # 1 of the patent.
And, both MS and Apple update do just this very thing.
I've not used RedHat since 6.0... but, I am familiar with Mandrake and Debian update systems. And, while IANAL, I don't see them in violation of at least claim # 1.
These systems send a generic list of available software to any computer requesting the list... and the client determines what to download.
Never is a list of installed software sent to the "update server".
Who would get sued for copyright infringements?
First rule of lawyering...
Don't sue people that can't pay.
(This is why the RIAA is doomed to failure with the lawsuit tactics, IMHO)
So, the answer is: who ever has the money.
Or... an ftp server listing.
Oh for crying out loud...
Can't you indent?
;-)
BTW, I think something is wrong with the fourth character tag...
My original points in this thread were concerning development of web applications for a company intranet.
The company decides on the browser requirements for its employees... including turning JavaScript on (or off).
If you are saying you can't do your job (use the intranet software) because you have disabled JavaScript (even tho the company policy is to enable it)... then you can explain the problem on your way out the door.
It isn't a personal decision in the context of employeement.
And that is the context of my remarks.
HTH
It is perfectly possible to use Javascript without making your website dependent upon it. Javascript was designed that way. Stop with the straw man arguments, nobody is suggesting a ban on Javascript.
Well, my point wasn't about "pushing" JavaScript.
My point was about using JavaScript to detect old and outdated browsers.
Someone else brought up the "but I don't have JavaScript enabled" blather.
That isn't my problem. If you don't want to meet the minimum requirements to use my site, then go away. It is my site (or the site of the person paying me) and the user is not part of the decision making process.
Options are weighed, decisions are made. Get over it.
Next, someone will say requiring a browser is "asking too much".
Not only that, but you are missing the point. The point is that JavaScript is REQUIRED as a design consideration. ON PURPOSE.
Yep, that is right. Someone is purposely making a decision to do something you (apparently) don't like... probably even something you or "they" consider to be a "bad" decision. I'm sure it won't be the last time that happens.
I'm not trying to make JavaScript optional, that isn't a goal. The goal is exactly the opposite. Anything that doesn't meet that goal, is failure.
If an employer here told an employee that they shouldn't use an intranet application because they are disabled, they'd be on the wrong end of a lawsuit very quickly.
Then don't say it is "because they are disabled". If that is the real reason, then there is a problem. And there should be trouble.
But, every job has skill requirements. And, the poeple doing the job should meet those requirements. People are not one to one interchangeable. So, every tool can not possibly be usable by every person.
That is life.
My point wasn't about "getting around" some accessibility law... it was about designing the tool for the people that are going to be doing the job. In the cases I've worked on to date, that meant people without disabilities.
The software designed by a company for it's EMPLOYEES should meet the needs of those people, not some imagined person that isn't there at the time and may never be. If none of them are disabled, then why should the product take into consideration a non-existant disability?
Next you would want to force Santa to have all of the tools in his workshop usable by "normal" sized people... even tho none of the workers are "normal" sized... and couldn't handle tools of that size to boot.
No browser supports getElementById() when they have Javascript switched off.
;-)
I gave a more serious answer above... here is the smartass answer.
You can explain why JavaScript was switched off to HR during your exit interview.
No browser supports getElementById() when they have Javascript switched off.
True.
But, I've yet to come across anyone that wants to pay to create a web *application* that is not also interested in some dynamic action.
It may be as simple as wanting to select all check boxes at once... or deselect them all at once.
This will either require JavaScript, Java, ActiveX... or some other technology above and beyond plain old HTML.
JavaScript is by far (IMHO) the least "bad" of the options. (For various definitions of "bad")
And, these applications are always (so far) inside the firewall (on the intranet) where the company can explicitly control what browser(s) will be used.
And, you can get around "accessibility requirements" by not requiring anyone with a disability to use the application.
Companies do it all the time. Most of them are in such a bind to get *something* up and running... that accessibility is way down on the list.
He parses his words carefully...
Dude!
Are you talking about the same guy?
;-)
;-)
I'm not even interested on bidding on a project that wants to support browsers that are so old (or lame) that they can't do a "getElementById".
I do it with three computers.
One dual Xeon system with a shitload of memory running Linux and VMWare... and several versions of Windows/IE via VMWare.
And, two Macs. One running OS9 and the other running OSX.
That gives me the greatest OS coverage with the minimum number of machines.
And... I load each OS with as many clients as I can test.
Use a corporate licence key.
The computers will most likely have a non-routable IP address assigned, and all of them will show up w/ the IP address of the firewall.
Even if they note the number of individual computers connecting w/ that license... there are so many "spares" and "rebuilds" in the corporate environment to make tracking a fruitless proposition.
Never had the boss say "I got it to work on my computer at home, you better damn well make it work here!" have you?
Not sure where you work, but every place I've worked... the "problem child" was the boss.
Seriously - in the windows camp, I don't think I've ever heard someone ignored for "asking a question wrong".
True, but Windows users are expected to be stupid. So, why waste time bitching about it?
They are wallets to be siphoned... and that takes a little grease.
You want to be treated nice in the "Linux community"... then, open your wallet and start shoving money at someone.
I'll take the hot chick with a brain.
Thanks!
Sure, but if the ratio is that much of a problem, then you are already into the "huge" catagory...
Just to be clear, the "problem" isn't the ratio... the ratio is close to "ideal" according to some people. The problem is that "average" people are not "ideal"... so, finding clothing is not easy if you are fit and closer to "ideal" than "average"... because the clothing is designed for the "average" person.
(man... that is a sh*tload of quotes...)
I hit that problem at 205 lbs... I didn't consider that "huge", even tho it was more muscular than virtually everyone I met (outside of the gym).
A normal suit is designed for an "8 inch drop" where the waist is 8 inches smaller than the chest. My chest was 46" and the waist was 32". The legs were even futher from "normal" because even the majority of gym rats don't work their lower body that much.
To me, "huge" is 280 lbs of raw muscle. Consider that Arnold's chest was 54" across... 46" is not close to the same category. Eight inches is a lot of beef in the chest area.
Anyways... I guess it is all a matter of perspective.