Had an argument about this awhile back.....the database listener services are not usually trusted as a secure thing for the outside world in my somewhat limited experience, there is always some kind of application layer as the public interface to these things (these days the outside world's interface is often HTTP based), particularly for services accessed over a WAN. How many people out there have oracle listening to an open port on the internet ?
ok, then i guess they can leave the internal interface wide open, run sloppy CGI scripts, and not encrypt any of the password files or anyhting, since the user should know to use a DMZ.
to repeat my other post, a shell is an executeable, just like a CGI. If "nobody" can execute a CGI, it can also execute a shell, or even more simply "echo 'Content-type: text/plain'; echo; cat/etc/passwd; cat/etc/ppp/pap-secrets" . Since the files are admittedly world readable anyway.
A very common configuration of a firewall is to let some incoming ports translate themselves to other boxes inside the network via NAT - this is to allow things like email services, web services, etc. be accessed. Even with all ports turned off to the outside world, Windows boxes receive email/word/AOL/etc viruses and trojans all the time. Therefore, the boxes *inside* a firewall are also never 100% safe from attack, meaning that a good firewall's security on the internal network interface is nearly, or in a large organization equally, important as that of the external interface.
if a cgi script running as "nobody" is compromised, then it is possible that the user "nobody" can gain shell access as well. A shell is simply another executeable, just like the CGI script itself.
He says shadow files are irrelvant as the box has only one account, root. Whatever happened to rule # 1 of having your web server and CGI's run as a different user ?
I have earthlink as well, and yes, they will not let you connect to port 25 on any host besides theirs. They are blocking the sending of spam using their network in any way, not just smtp relaying. Now THAT policy sucks. The Verizon thing only refers to what kind of data you send to their smtp servers.
It would be much appreciated if anyone can point me to an official mention of earthlink's policy, since I have observed it but could find nothing about it on their site or within their tech support section.
Makes web development impossible - hit a.cgi script or some other dynamic file, view source on it. Fine, now go back, change the script, press reload and get the new HTML content reflecting the changes in the script. View source again, whoops, even though the HTML changed, the view source gives you the old source still!
it is a protocol for invoking methods via XML whose development is being led by Microsoft. Its many enthusiastic headlines on Slashdot leave me quite suspicious of slashdot's editors either being extremely naive or extremely devious (under the directorship of VA Linux and their vanishing business model).
Yes, its BS protection, its probably a cripple in the napster client. Easy enough to use a different Napster client. Unless the fed then shuts down the usage of alternate Napster clients in the same manner DeCSS is illegal. Then the precedents would be all around to begin the total systematic criminalization of any software that isnt produced by a big corporation.....Im sure MS will have quite a few many other usages for precedents like this.
Stroustrup is famous for being very anti-Java. Most people figure he's just jealous that it caught on a million times faster than his creation of C++, while mimicking some (but certainly not all) of the concepts in C++.
So here we have another guy who is very fluent in C++ and therefore thinks everyone else should do everything in C++ as well. Im sure the "C++ is so much faster" arguments can't be far away either.
I think while C++ applications are faster and are good at hiding inefficiencies in code (if you consider that to be an advantage, i dont), and there can be an endless ongoing argument about which platform allows superior architecture (I think it works out to be nearly the same in the end), it is nearly impossible to argue that the learning curve, rate of development, or deliverable design/implementation quality from an average (i.e., not genius, most programmers are not) programmer with C++ is at all comparable to that of Java.
Also, Java is somewhat proprietary, but certainly not the way Win32 is. Theres tons of VM's out there and anyone can write their own and not get sued. Shouldnt be a problem there except for Stroustrups frustration over his lack of ubiquity.
It is illegal if you own a copy of windows? Does this license specify the required runtime context of the legally-owned OS components? Is it illegal to run Windows OS components under VMWare? Otherwise it should be perfectly legal to run under Wine.
I installed it, ran Notepad, that was OK, tried IE, it churned for about half an hour and dumped about 5000 lines of debug code....nothing. Too soon to focus on 3D support yet?
true, but the tone of the slashdot post as well as the overall mood here is that spamming itself should be illegal as well. I think illegalizing mass-email itself is really dangerous, since such a law can likely be stretched by those in power to inhibit the electronic versions of things like policial campaigns, anti-government/corporate protests, boycotts, etc.
It is quite easy to use on the server side, just use an API like Xalan, and call about three methods and give it a Writer to send the data to. We are processing documents in batch mode so we dont have to worry about the speed. We are in fact using moderately complex style sheets, they work fine. I like that I can have an outside vendor continue to tweak them without them having to mess up our code. Im sorry I havent worked with DSSSL, but maybe you are taking your bad experiences with that standard and interpolating them onto XSL. Im not saying XSL is so mature and wonderfully perfect but converting XML to other formats is a very redundant task, and to have to write custom code and recompile every time a tag changes is ridiculous....my experience is that once you do something with code, no matter how clean and simple it is, its 10 times more difficult to get someone else to maintain it once youve moved onto other projects. Xsl, whether or not you think its ugly, can be effectively messed with by all sorts of non-programmers and scripter types who flee in terror at having to type "javac" for something.
very interesting. My current project deals with XML documents, and I was going full-on converting them to Java objects so that I might have the most flexibility in displaying them. I intended to display using JSP, although I am the original co-creator of the now-defunct Freemarker, so I know where youre coming from with the Webmacro thing too.
As it turns out, we are converting bits and pieces of our XML to java objects (business-specific objects, not DOM objects...to display DOM directly in a template or JSP would violate abstraction of business rules, IMHO), but at the moment its a pain to write parsers to populate the objects, you write the same code over and over again. I have found very few packages to automate this process, and they are not flexible enough, and also Sun has a plan for a generic xml->object deserialization format, but thats a specific set of XML tags (ironically youd use XSL to convert from your own tagset to the java-centric one!). I looked into making some kind of API that takes an object that maps tags in various relationships to properties and methods, but I think by the time Im halfway done with that theres going to be something up on xml.apache.org that does it better. For a large chunk of our XML, we just need to display an HTML document, and we have a tag vendor doing lots of that effort; i trust them much more writing XSL sheets for me instead of coding our java objects and JSP pages. So the data that we need more run-time flexibilty with is still being converted to Java objects, but the mass of these docs (and they are big! huge dtds too) are just going to pump through XSL. I think its the issue of the right tool for the job.
XSLT can just as easily be used on the server side, to act as a language-neutral template that is read by your perl script, PHP script, servlet, etc. to produce the final output. It does not preclude the usage of those technologies, it simply moves the nitty-gritty about text formatting into a separate document that is much easier for programmers and not-such-programmers alike to deal with, without breaking your application.
For people dealing with very large and varied sets of XML formats and multiple display formats (as industries like publishing do), it is infinitely more maintainable to have the conversions to HTML, plain text, PDF, other XML, etc. written out as a set of XSL sheets instead of your proposed solution, i.e. one rat's nest of perl script after another. XSLT is barely a scripting language, and is rigidly defined, which means looking at one XSL template or another for the first time is far less of a crap shoot than opening yet another perl script or Java class that does it in yet another non-standard, confusing, error-prone, and inflexible way.
Slashdot Mirror
The often questionable quality of Open Source code can only take a nosedive if we start throwing CS-major lightweights at it....
and the USA about the titanic
Had an argument about this awhile back.....the database listener services are not usually trusted as a secure thing for the outside world in my somewhat limited experience, there is always some kind of application layer as the public interface to these things (these days the outside world's interface is often HTTP based), particularly for services accessed over a WAN. How many people out there have oracle listening to an open port on the internet ?
ok, then i guess they can leave the internal interface wide open, run sloppy CGI scripts, and not encrypt any of the password files or anyhting, since the user should know to use a DMZ.
to repeat my other post, a shell is an executeable, just like a CGI. If "nobody" can execute a CGI, it can also execute a shell, or even more simply "echo 'Content-type: text/plain'; echo; cat /etc/passwd; cat /etc/ppp/pap-secrets" . Since the files are admittedly world readable anyway.
This is like super-basic security, folks.
A very common configuration of a firewall is to let some incoming ports translate themselves to other boxes inside the network via NAT - this is to allow things like email services, web services, etc. be accessed. Even with all ports turned off to the outside world, Windows boxes receive email/word/AOL/etc viruses and trojans all the time. Therefore, the boxes *inside* a firewall are also never 100% safe from attack, meaning that a good firewall's security on the internal network interface is nearly, or in a large organization equally, important as that of the external interface.
if a cgi script running as "nobody" is compromised, then it is possible that the user "nobody" can gain shell access as well. A shell is simply another executeable, just like the CGI script itself.
it has cgi-based configuration scripts which would imply a webserver as well.
He says shadow files are irrelvant as the box has only one account, root. Whatever happened to rule # 1 of having your web server and CGI's run as a different user ?
I have earthlink as well, and yes, they will not let you connect to port 25 on any host besides theirs. They are blocking the sending of spam using their network in any way, not just smtp relaying. Now THAT policy sucks. The Verizon thing only refers to what kind of data you send to their smtp servers.
It would be much appreciated if anyone can point me to an official mention of earthlink's policy, since I have observed it but could find nothing about it on their site or within their tech support section.
Makes web development impossible - hit a .cgi script or some other dynamic file, view source on it. Fine, now go back, change the script, press reload and get the new HTML content reflecting the changes in the script. View source again, whoops, even though the HTML changed, the view source gives you the old source still!
it is a protocol for invoking methods via XML whose development is being led by Microsoft. Its many enthusiastic headlines on Slashdot leave me quite suspicious of slashdot's editors either being extremely naive or extremely devious (under the directorship of VA Linux and their vanishing business model).
Yes, its BS protection, its probably a cripple in the napster client. Easy enough to use a different Napster client. Unless the fed then shuts down the usage of alternate Napster clients in the same manner DeCSS is illegal. Then the precedents would be all around to begin the total systematic criminalization of any software that isnt produced by a big corporation.....Im sure MS will have quite a few many other usages for precedents like this.
new movement.....in order to preserve the quality of Slashdot feedback, every headline must now look like:
SDAFLJQ#$RLWEFQ$FSDFDF#$QVQ $#RFclick SADFAS!FEQWsk3n1443R$:FEMK #VL#$ VJLF34knc rk4jnc#$ C%$@
So i hope to get you all signed up pronto.
that will propose that all Slashdot headlines make some semblance of sense without having to read the external site to see what its talking about.
Stroustrup is famous for being very anti-Java. Most people figure he's just jealous that it caught on a million times faster than his creation of C++, while mimicking some (but certainly not all) of the concepts in C++.
So here we have another guy who is very fluent in C++ and therefore thinks everyone else should do everything in C++ as well. Im sure the "C++ is so much faster" arguments can't be far away either.
I think while C++ applications are faster and are good at hiding inefficiencies in code (if you consider that to be an advantage, i dont), and there can be an endless ongoing argument about which platform allows superior architecture (I think it works out to be nearly the same in the end), it is nearly impossible to argue that the learning curve, rate of development, or deliverable design/implementation quality from an average (i.e., not genius, most programmers are not) programmer with C++ is at all comparable to that of Java.
Also, Java is somewhat proprietary, but certainly not the way Win32 is. Theres tons of VM's out there and anyone can write their own and not get sued. Shouldnt be a problem there except for Stroustrups frustration over his lack of ubiquity.
sometimes the benifits of HTML mail are important.
Such as? Particularly when HTML these days also means scripting languages, embedded objects, etc.
It is illegal if you own a copy of windows? Does this license specify the required runtime context of the legally-owned OS components? Is it illegal to run Windows OS components under VMWare? Otherwise it should be perfectly legal to run under Wine.
I installed it, ran Notepad, that was OK, tried IE, it churned for about half an hour and dumped about 5000 lines of debug code....nothing. Too soon to focus on 3D support yet?
The United States Supreme Court! Oh...wait.....um..
Just think, the freedom of our harddrives is in the hands of this man.
I wonder if big industry executives can even take him seriously with that kind of attitude.
true, but the tone of the slashdot post as well as the overall mood here is that spamming itself should be illegal as well. I think illegalizing mass-email itself is really dangerous, since such a law can likely be stretched by those in power to inhibit the electronic versions of things like policial campaigns, anti-government/corporate protests, boycotts, etc.
It is quite easy to use on the server side, just use an API like Xalan, and call about three methods and give it a Writer to send the data to. We are processing documents in batch mode so we dont have to worry about the speed. We are in fact using moderately complex style sheets, they work fine. I like that I can have an outside vendor continue to tweak them without them having to mess up our code. Im sorry I havent worked with DSSSL, but maybe you are taking your bad experiences with that standard and interpolating them onto XSL. Im not saying XSL is so mature and wonderfully perfect but converting XML to other formats is a very redundant task, and to have to write custom code and recompile every time a tag changes is ridiculous....my experience is that once you do something with code, no matter how clean and simple it is, its 10 times more difficult to get someone else to maintain it once youve moved onto other projects. Xsl, whether or not you think its ugly, can be effectively messed with by all sorts of non-programmers and scripter types who flee in terror at having to type "javac" for something.
very interesting. My current project deals with XML documents, and I was going full-on converting them to Java objects so that I might have the most flexibility in displaying them. I intended to display using JSP, although I am the original co-creator of the now-defunct Freemarker, so I know where youre coming from with the Webmacro thing too.
As it turns out, we are converting bits and pieces of our XML to java objects (business-specific objects, not DOM objects...to display DOM directly in a template or JSP would violate abstraction of business rules, IMHO), but at the moment its a pain to write parsers to populate the objects, you write the same code over and over again. I have found very few packages to automate this process, and they are not flexible enough, and also Sun has a plan for a generic xml->object deserialization format, but thats a specific set of XML tags (ironically youd use XSL to convert from your own tagset to the java-centric one!). I looked into making some kind of API that takes an object that maps tags in various relationships to properties and methods, but I think by the time Im halfway done with that theres going to be something up on xml.apache.org that does it better. For a large chunk of our XML, we just need to display an HTML document, and we have a tag vendor doing lots of that effort; i trust them much more writing XSL sheets for me instead of coding our java objects and JSP pages. So the data that we need more run-time flexibilty with is still being converted to Java objects, but the mass of these docs (and they are big! huge dtds too) are just going to pump through XSL. I think its the issue of the right tool for the job.
XSLT can just as easily be used on the server side, to act as a language-neutral template that is read by your perl script, PHP script, servlet, etc. to produce the final output. It does not preclude the usage of those technologies, it simply moves the nitty-gritty about text formatting into a separate document that is much easier for programmers and not-such-programmers alike to deal with, without breaking your application.
For people dealing with very large and varied sets of XML formats and multiple display formats (as industries like publishing do), it is infinitely more maintainable to have the conversions to HTML, plain text, PDF, other XML, etc. written out as a set of XSL sheets instead of your proposed solution, i.e. one rat's nest of perl script after another. XSLT is barely a scripting language, and is rigidly defined, which means looking at one XSL template or another for the first time is far less of a crap shoot than opening yet another perl script or Java class that does it in yet another non-standard, confusing, error-prone, and inflexible way.