But not today of course, and probably not for a long time, if ever, assuming MS hold on to their patents.
There's a huge difference between cloning the CLR and the Dotnet Framework, that's why most serious cross-(hardware)-platform apps on Linux use Java, Python or Perl.
I especially used to enjoy helping damsels in distress who had a new hairdryer
I was just gonna write that. I know a German lady who was in a store and wondered how to get a plug on her lamp, so some chap volunteered. And they lived happily ever after - ahhhh!
Not sure if this makes up for all those people that put the earth wire in the live pin though.
Didn't this used to be part of a Physics exam? I'm sure my mum used to teach it.
I'm not convinced that you have really embraced your 'presence' mechanism - it sounds rather as if you'd prefer to treat it as some sort of parallel and separate communication phenomenon. In reality, establishing presence takes you back to square one - you need "live" (i.e. synchronous) interaction to track it.
Now having developed message delivery and tracking mechanisms, it seems a trifle defeatist to deny that you have invented a guaranteed delivery system. Somebody somewhere is recording what each party has received, and ultimately this information can be accessed by a client interested in finding this out.
Latency is a consequence of tracking the state of a distributed system in any form. The good news is that there are plenty of interesting design choices that can be made to minimize it, and I suggest that this is where the Jabber designers should concentrate their efforts.
One thing is that jabber was presented as a solution [...] for asynchronous transfer of XML.
A store-and-forward network, in other words. That's great, but to actually add value over email you need to know whether the other party is there, whether they've read your message etc.
These are examples of what workflow people call 'process state' information and, perhaps surprisingly, this requires synchronous communication to track. "Messaging" products are always sold as providing a completely asynchronous solution, then awkward details such as guaranteed delivery, resend requests and process state queries raise their heads and suddenly the wonderful asynchronous model needs supplementing with good old RPC again.
Jabber protocols should all be implemented as synchronous and RPC-like at the detail level - any "asynchrony" will emerge from the use of store-and-forward queues, which each party will interact with using simple RPC.
I assume that Jabber isn't already like this because XML-RPC is identified as an extension to the basic protocol rather than the other way around, but feel free to enlighten me.
Fair comment - I forgot I'd had problems with my CD-R/W. The installation does what you'd expect by creating an IDE driver-based cdrom device and a SCSI-on-IDE cdrecorder device, but the former doesn't work in this situation (on both my laptop and desktop) - don't know why. Solution for me was to link/media/cdrom to/media/cdrecorder, i.e. always go through the SCSI layer.
Pays to read carefully - the comparison was with SuSE 8, not RedHat. SuSE has a bunch of specific hardware detection stuff that RH doesn't.
I can confirm his experience - the critical timesavers for me were firstly that SuSE 8 supported my inbuilt laptop LAN port whereas Win 2K did not, so I could get going straightaway with downloading KDE updates etc.
Secondly Win2K required numerous reboots to add drivers. And unluckily for me, even more reboots to uninstall problematic updates - i.e. per individual KB fix.
MS are supposed to log every reboot requirement as a bug, but as with security, identifying the problem is not the same as addressing it.
Having said this, my guess is that once Dotnet gets established in the OS, MS will be able to breeze past Linux in the manageability stakes.
The problem you appear to be encountering is that you interpret 'use/utilize' to be a conscious act and one which users will be able to identify and predict. No such meaning necessarily applies.
In fact, the wording is so vague Microsoft could associate this permission with any product or mechanism they choose, given the pervasiveness of 'internet-based services' such as IE.
With reference to your earlier posts, I'm obliged to point out that these are far from consistent in the argument that they are advancing. In order, we have:
1) The suggestion that any machine connected to the net contravenes the HIPAA and that therefore the whole debate is moot. Presumably because this is obviously an impractical limitation, no further mention is made of it.
2) The suggestion of a technical fix to the auto-update mechanism to prevent it from functioning. Several responses then point out that the problem lies with the license, not any specific mechanism.
3) Several posts quoting the portion of the EULA concerning opt-in auto-updates, omitting the general update permission clause. This is in an effort to prove that auto-update requires explicit permission.
4) After apparently retreating from (3), a new proposition is advanced that auto-update, while admittedly not being under explicit control of the user, applies only to mechanisms consciously 'utilized'. Presumably the implication is that the user will always be aware of such use and therefore should not be surprised by an auto-update.
5) A synthesis of (2) and (4) is then proposed where by 'firewalling the box' the mechanisms in (4) will be used and therefore the general auto-update clause does not apply. This is then immediately undermined by the admission that firewalling does not prevent mechanisms from accessing the internet, and so "[a]ny of [sic] MS's software that uses the Internet can check itself and update itself.". This doesn't prevent the same argument being forwarded again later, this time with the recommendation to use SUS to distribute patches as a workaround.
6) Yet another new angle is introduced, this time that the EULA itself can be disregarded because any 'illegal or unreasonable' clause will be found invalid when legally tested. It is not clear how this relates to previous points made.
It seems from this summary that you are content to chop and change your argument as you go along, shifting ground from one proposition to the other where necessary, only to restate earlier points in other places. It might be better for all concerned if you drew together whichever parts of the statements above now constitute your position and posted it once for further discussion.
...but also misleading, as an AC has already pointed out. Here's the paragraph subsequent to the one that's been repeatedly quoted:
The OS Product or OS Components contain components that enable and facilitate the use of certain Internet-based services. You acknowledge and agree that Microsoft may automatically check the version of the OS Product and/or its components that you are utilizing and may provide upgrades or fixes to the OS Product that will be automatically downloaded to your computer.
Because this is outside the context of the auto-updating feature paragraph there is no obligation on Microsoft's part to apply any user choice there to this mechanism.
Breaking confidentiality via the actions of authorized staff is a different risk. The question is about the act of assigning external parties privileges that itself breaks confidentiality agreements.
go ahead, get Windows SP3, and then figure out some way to disable remote-root.
No lawyer is going to recommend this because there's no guarantee that a technical fix will work or will not compromise some other clause or agreement.
A new contract needs to be drawn up in place of the EULA. I would recommend this for all IT licensing, not just for MS products - shrinkwrap EULAs are of dubious legality at best, especially in Europe.
The question relates to the license not to the technology. Technical fixes might be a fascinating subject in their own right but they are irrelevant in this case.
I'm sure I'd be more of a Unix fan if I'd not worked with something like VOS. All the components in these fault-tolerant machines were hotpluggable, and all device drivers dynamically loadable and reloadable.
I think my favourite feature was the utterly predictable naming of commands - no umount here.
VOS was designed in the late 70s, based on the legendary Multics.
Anyway, the important thing is not to make excuses for the various problems we've inherited but to organize and develop something better.
You might be right, but I read somewhere that Sky gets more revenue than the BBC having surpassed them about 3 years ago, though possibly before the last license fee increase.
I admit I'm no expert - another weirdo with no TV!
Sounds more as if you've moved from a mostly Apache/Tomcat environment with some bit in WebLogic to... a mostly Apache/Tomcat environment with some bit in JBoss. Sounds perfectly reasonable, but I don't see anything in your post to justify the heaven and hell hyperbole.
Huh? If statements like we replaced BEA with [JBoss] for commercial product deploys and have been thrilled and I must agree 100% with you. I work as a consultant and I have helped 3 companies to switch from WebLogic to JBoss. are not claiming that JBoss is better than WebLogic, what exactly are they claiming?
What makes you think I haven't looked at or worked with JBoss? WebLogic happens to be the main source of my income but I do work with a number of competing products, both in the web server space ([E]JBoss, WebSphere, EAServer and Orion/Oracle) and in the EAI space (Tibco, MQSeries).
I appreciate your concern, but I'm quite capable of judging the rival merits of WebLogic and JBoss.
I've worked with JBoss since before it was JBoss, and before it had any kind of support. I think it's fine as far as it goes, but your generalizations are not much more helpful than the original bit of flag-waving.
You appear to forget that some real customers are interested in things like usable security (not freeware Java SSL implementations), clustering that works with real hardware and centralized management for servers and applications.
These customers often also want to be in a position to handle future stuff like workflow and web services conveniently - not via 101 addons from different projects scattered around the web. This is what the Platform is giving them - the only competing strategy for this is from Microsoft.
If BEA were still selling 6.0 and had no coherent plan then you might have a point, but until JBoss has something that really is as comprehensive and functional there are going to be sufficient reasons for corporates to choose WebLogic.
I have shared your pain on the support side in the past (I've spent most of my time on the other side of the fence) but since the Web Support went live I've had no problem organizing things such as continuous, 24 hour attention to specific issues, with a problem being passed to engineers around the world in the middle of the night, and who I can talk to via one 800 number.
And for what it's worth, the BEA consultants I've worked with over here have been among the most clued up I've encountered from any organization. Unlike a lot of technology outfits offering consultancy, they tend to be old hands who can fix all kinds of stuff outside WebLogic - from routers to Solaris sys admin to Emacs init files - if the occasion demands. Sorry if your experience was different.
Well, it's pretty good actually, no need to put Apache in there just for that - it creates an access.log file just the same. Check the Server HTTP Logging help page. Only thing it doesn't do is merge the access logs for you across different servers in a cluster like it can do with normal logs - too much traffic I guess.
Filters appear in WebLogic 7 (they came in servlet 2.3 I think) - you write the class and then mention it in the web app deployment descriptor, e.g. using WebLogic Builder.
Guys, you are being a little unfair here - the poster makes:
5 statements describing
4 problems
2 of which were fixed years ago
leaving
2 of such vague description you have no idea whether they're relevant to you.
SAX not working? That's odd, because he's using Xerces and Xalan - not BEA code. They are shipped with WebLogic, but we don't know if he's using these or standalone versions. Whatever - these are unlikely to be WebLogic-specific problems.
Closing and opening streams causes problems? I should think it does - last time I looked the servlet specification didn't exactly encourage people to do this in the middle of processing requests.
Informative? I doubt if it's relevant to one other reader here.
simply because of an outdated association with the slow cgi stuff.
It's more than that. Even with mod_perl, you're still lacking the efficient thread support of a Java web app server - this really matters when your concurrency level starts rising and Apache starts running out of back-end processes.
And Java has a comprehensive security model, handles in-flight update and redeployment better, includes centralized management tools, has straightforward session and clustering support in many implementations, flexible and efficient database integration, not to mention a healthy market in applications and tools.
These are some of the reasons Perl loses out in big developments - it has some nice features of its own but these aren't generally considered as critical.
Slashdot Mirror
a new Windows codebase is needed
Presumably Dotnet?
Unfortunately, Linux isn't converging on anything similar - we've got Java, Mono, DotGNU, Parrot etc.
Where security is thought of at all (Java, and the Dotnet clones by reference) it is not with a view to producing a consistent platform.
The same kind of problem will arise in moving to a database-backed file system (equivalent to Windows' 'Longhorn' plans).
'Linus doesn't do strategy' as someone accurately but rather meanly pointed out here.
But not today of course, and probably not for a long time, if ever, assuming MS hold on to their patents.
There's a huge difference between cloning the CLR and the Dotnet Framework, that's why most serious cross-(hardware)-platform apps on Linux use Java, Python or Perl.
I especially used to enjoy helping damsels in distress who had a new hairdryer
I was just gonna write that. I know a German lady who was in a store and wondered how to get a plug on her lamp, so some chap volunteered. And they lived happily ever after - ahhhh!
Not sure if this makes up for all those people that put the earth wire in the live pin though.
Didn't this used to be part of a Physics exam? I'm sure my mum used to teach it.
I'm not convinced that you have really embraced your 'presence' mechanism - it sounds rather as if you'd prefer to treat it as some sort of parallel and separate communication phenomenon. In reality, establishing presence takes you back to square one - you need "live" (i.e. synchronous) interaction to track it.
Now having developed message delivery and tracking mechanisms, it seems a trifle defeatist to deny that you have invented a guaranteed delivery system. Somebody somewhere is recording what each party has received, and ultimately this information can be accessed by a client interested in finding this out.
Latency is a consequence of tracking the state of a distributed system in any form. The good news is that there are plenty of interesting design choices that can be made to minimize it, and I suggest that this is where the Jabber designers should concentrate their efforts.
One thing is that jabber was presented as a solution [...] for asynchronous transfer of XML.
A store-and-forward network, in other words. That's great, but to actually add value over email you need to know whether the other party is there, whether they've read your message etc.
These are examples of what workflow people call 'process state' information and, perhaps surprisingly, this requires synchronous communication to track. "Messaging" products are always sold as providing a completely asynchronous solution, then awkward details such as guaranteed delivery, resend requests and process state queries raise their heads and suddenly the wonderful asynchronous model needs supplementing with good old RPC again.
Jabber protocols should all be implemented as synchronous and RPC-like at the detail level - any "asynchrony" will emerge from the use of store-and-forward queues, which each party will interact with using simple RPC.
I assume that Jabber isn't already like this because XML-RPC is identified as an extension to the basic protocol rather than the other way around, but feel free to enlighten me.
Fair comment - I forgot I'd had problems with my CD-R/W. The installation does what you'd expect by creating an IDE driver-based cdrom device and a SCSI-on-IDE cdrecorder device, but the former doesn't work in this situation (on both my laptop and desktop) - don't know why. Solution for me was to link /media/cdrom to /media/cdrecorder, i.e. always go through the SCSI layer.
Pays to read carefully - the comparison was with SuSE 8, not RedHat. SuSE has a bunch of specific hardware detection stuff that RH doesn't.
I can confirm his experience - the critical timesavers for me were firstly that SuSE 8 supported my inbuilt laptop LAN port whereas Win 2K did not, so I could get going straightaway with downloading KDE updates etc.
Secondly Win2K required numerous reboots to add drivers. And unluckily for me, even more reboots to uninstall problematic updates - i.e. per individual KB fix.
MS are supposed to log every reboot requirement as a bug, but as with security, identifying the problem is not the same as addressing it.
Having said this, my guess is that once Dotnet gets established in the OS, MS will be able to breeze past Linux in the manageability stakes.
Interesting post.
On the 'weakly hierarchical' front, surely both sexps and XML are limited if all your (say) italic and bold sections are different but overlap?
There seems to be a requirement for an extra level of indirection here - a solution to all CS problems, as we know.
Apparently there are two EULA texts - one comes up before you download, the other during the install. Guess which is the more constraining?
/. discussions.
I haven't installed SP3 so I'm afraid I can't be more precise - suggest you check earlier
The problem you appear to be encountering is that you interpret 'use/utilize' to be a conscious act and one which users will be able to identify and predict. No such meaning necessarily applies.
In fact, the wording is so vague Microsoft could associate this permission with any product or mechanism they choose, given the pervasiveness of 'internet-based services' such as IE.
With reference to your earlier posts, I'm obliged to point out that these are far from consistent in the argument that they are advancing.
In order, we have:
1) The suggestion that any machine connected to the net contravenes the HIPAA and that therefore the whole debate is moot. Presumably because this is obviously an impractical limitation, no further mention is made of it.
2) The suggestion of a technical fix to the auto-update mechanism to prevent it from functioning. Several responses then point out that the problem lies with the license, not any specific mechanism.
3) Several posts quoting the portion of the EULA concerning opt-in auto-updates, omitting the general update permission clause. This is in an effort to prove that auto-update requires explicit permission.
4) After apparently retreating from (3), a new proposition is advanced that auto-update, while admittedly not being under explicit control of the user, applies only to mechanisms consciously 'utilized'. Presumably the implication is that the user will always be aware of such use and therefore should not be surprised by an auto-update.
5) A synthesis of (2) and (4) is then proposed where by 'firewalling the box' the mechanisms in (4) will be used and therefore the general auto-update clause does not apply. This is then immediately undermined by the admission that firewalling does not prevent mechanisms from accessing the internet, and so "[a]ny of [sic] MS's software that uses the Internet can check itself and update itself.". This doesn't prevent the same argument being forwarded again later, this time with the recommendation to use SUS to distribute patches as a workaround.
6) Yet another new angle is introduced, this time that the EULA itself can be disregarded because any 'illegal or unreasonable' clause will be found invalid when legally tested. It is not clear how this relates to previous points made.
It seems from this summary that you are content to chop and change your argument as you go along, shifting ground from one proposition to the other where necessary, only to restate earlier points in other places. It might be better for all concerned if you drew together whichever parts of the statements above now constitute your position and posted it once for further discussion.
...but also misleading, as an AC has already pointed out. Here's the paragraph subsequent to the one that's been repeatedly quoted:
The OS Product or OS Components contain components that enable and facilitate the use of certain Internet-based services. You acknowledge and agree that Microsoft may automatically check the version of the OS Product and/or its components that you are utilizing and may provide upgrades or fixes to the OS Product that will be automatically downloaded to your computer.
Because this is outside the context of the auto-updating feature paragraph there is no obligation on Microsoft's part to apply any user choice there to this mechanism.
Breaking confidentiality via the actions of authorized staff is a different risk. The question is about the act of assigning external parties privileges that itself breaks confidentiality agreements.
go ahead, get Windows SP3, and then figure out some way to disable remote-root.
No lawyer is going to recommend this because there's no guarantee that a technical fix will work or will not compromise some other clause or agreement.
A new contract needs to be drawn up in place of the EULA. I would recommend this for all IT licensing, not just for MS products - shrinkwrap EULAs are of dubious legality at best, especially in Europe.
The question relates to the license not to the technology. Technical fixes might be a fascinating subject in their own right but they are irrelevant in this case.
I'm sure I'd be more of a Unix fan if I'd not worked with something like VOS. All the components in these fault-tolerant machines were hotpluggable, and all device drivers dynamically loadable and reloadable.
I think my favourite feature was the utterly predictable naming of commands - no umount here.
VOS was designed in the late 70s, based on the legendary Multics.
Anyway, the important thing is not to make excuses for the various problems we've inherited but to organize and develop something better.
Not exactly fair, no. But then I have to pay tax of £150 a year to keep my car on the road and I do a lot fewer miles than average.
As it happens I haven't had a TV since the mid-80s, but that's not because I thought the funding model was wrong.
You might be right, but I read somewhere that Sky gets more revenue than the BBC having surpassed them about 3 years ago, though possibly before the last license fee increase.
I admit I'm no expert - another weirdo with no TV!
Sounds more as if you've moved from a mostly Apache/Tomcat environment with some bit in WebLogic to... a mostly Apache/Tomcat environment with some bit in JBoss. Sounds perfectly reasonable, but I don't see anything in your post to justify the heaven and hell hyperbole.
[author is independent WebLogic consultant]
I was even FORCED to use THEIR IDE later.
;-)
BEA didn't sell an IDE. Maybe thinking of IBM?
Huh? If statements like
we replaced BEA with [JBoss] for commercial product deploys and have been thrilled
and
I must agree 100% with you. I work as a consultant and I have helped 3 companies to switch from WebLogic to JBoss.
are not claiming that JBoss is better than WebLogic, what exactly are they claiming?
What makes you think I haven't looked at or worked with JBoss? WebLogic happens to be the main source of my income but I do work with a number of competing products, both in the web server space ([E]JBoss, WebSphere, EAServer and Orion/Oracle) and in the EAI space (Tibco, MQSeries).
I appreciate your concern, but I'm quite capable of judging the rival merits of WebLogic and JBoss.
I've worked with JBoss since before it was JBoss, and before it had any kind of support. I think it's fine as far as it goes, but your generalizations are not much more helpful than the original bit of flag-waving.
You appear to forget that some real customers are interested in things like usable security (not freeware Java SSL implementations), clustering that works with real hardware and centralized management for servers and applications.
These customers often also want to be in a position to handle future stuff like workflow and web services conveniently - not via 101 addons from different projects scattered around the web. This is what the Platform is giving them - the only competing strategy for this is from Microsoft.
If BEA were still selling 6.0 and had no coherent plan then you might have a point, but until JBoss has something that really is as comprehensive and functional there are going to be sufficient reasons for corporates to choose WebLogic.
I have shared your pain on the support side in the past (I've spent most of my time on the other side of the fence) but since the Web Support went live I've had no problem organizing things such as continuous, 24 hour attention to specific issues, with a problem being passed to engineers around the world in the middle of the night, and who I can talk to via one 800 number.
And for what it's worth, the BEA consultants I've worked with over here have been among the most clued up I've encountered from any organization. Unlike a lot of technology outfits offering consultancy, they tend to be old hands who can fix all kinds of stuff outside WebLogic - from routers to Solaris sys admin to Emacs init files - if the occasion demands. Sorry if your experience was different.
Well, it's pretty good actually, no need to put Apache in there just for that - it creates an access.log file just the same. Check the Server HTTP Logging help page. Only thing it doesn't do is merge the access logs for you across different servers in a cluster like it can do with normal logs - too much traffic I guess.
Filters appear in WebLogic 7 (they came in servlet 2.3 I think) - you write the class and then mention it in the web app deployment descriptor, e.g. using WebLogic Builder.
Guys, you are being a little unfair here - the poster makes:
5 statements describing
4 problems
2 of which were fixed years ago
leaving
2 of such vague description you have no idea whether they're relevant to you.
SAX not working? That's odd, because he's using Xerces and Xalan - not BEA code. They are shipped with WebLogic, but we don't know if he's using these or standalone versions. Whatever - these are unlikely to be WebLogic-specific problems.
Closing and opening streams causes problems? I should think it does - last time I looked the servlet specification didn't exactly encourage people to do this in the middle of processing requests.
Informative? I doubt if it's relevant to one other reader here.
No they don't - check here.
What's much more interesting is that Linux on Intel (OK, and probably Wintel too) is the prime focus of BEA's own JRockit VM.
With Sun, IBM and BEA all investing heavily, the outlook for Java on Linux has never looked better.
simply because of an outdated association with the slow cgi stuff.
It's more than that. Even with mod_perl, you're still lacking the efficient thread support of a Java web app server - this really matters when your concurrency level starts rising and Apache starts running out of back-end processes.
And Java has a comprehensive security model, handles in-flight update and redeployment better, includes centralized management tools, has straightforward session and clustering support in many implementations, flexible and efficient database integration, not to mention a healthy market in applications and tools.
These are some of the reasons Perl loses out in big developments - it has some nice features of its own but these aren't generally considered as critical.