Microsoft apologist? What does that mean, exactly?
An apologist is one who argues in defense of something, in this case the person is arguing in defense of Microsoft's shoddy security practices. Not sure why you're bringing monopolistic practices into this.
For the most part, you'll be fine as long as you exercise some clue. Keep up to date on OS and application patches, run a good antivirus program, stay behind a firewall, and don't use insecure software (such as IE/Outlook);...
Yeah no shit. But why should anyone have to jump through these hoops? It might not be a big deal for you, but if you look at the evidence, this is a HUGE issue for most of the population. As a slashdot reading geek, you of all people should have higher expectations of the software you use.
By the way - your analogy was terrible.
Glad you liked it. It was intended to be a touch ridiculous, just like the parent's.
The computer didn't just up and die on its own. It was systematically attacked by OTHER COMPUTERS through the DSL network connection.
Right, OTHER COMPUTERS all infected due to Microsoft security flaws. It was infected because the software installed on it DOESN'T WORK like it should. I find it remarkable that people have such low expectations of software that they are willing to defend such a situation by blaming the user. Not everyone is a slashdot reading geek (for which we should be extremely grateful.)
The original analogy that compared that to someone else hitting your car is accurate.
Maybe, if within 4 minutes of pulling out of the driveway and parking beside the curb on a safe street, you could expect to get hit by dozens of cars because you forgot to purchase and install the extra bonus safety reflectors that the dealer neglected to tell you about. Try again.
Cars don't suck because they crash when people drive drunk, the drivers do. Windows doesn't suck when idiots connect it to a high speed network unprotected, the moron using it does.
Not a very accurate analogy. Wouldn't it suck if the car were to unconditionally burst into flames unless you were sure to also purchase an extra $1000 in "safety features" and have them installed perfectly before ever attempting to drive it? (And without the dealer actually telling you this.)
Get it now? You microsoft apologists should really get a clue.
"binary xml" is simply a shorter way of saying something like "binary serialization of the XML infoset". The binary XML guys like to be concise and compact in their terminology in addition to their representations:-)
Exactly... the question shouldn't be "Does the world need Binary XML?" because the answer is "the world already has it, about 1000 different kinds in fact!" It's not like Tim Bray's whining is going to make it go away. ("Waaaahh... someone doesn't like my stuff!")
The question should instead be "How can we best standardize binary XML?"
My main fear is the typical "design by committee" style of standards bodies will lead to a super-bloated binary standard containing every pet feature of each participant. This could make it just as slow and painful as working with any textual encoding. I think Mike Conner's "CBXML" is probably the right mix of simplicity, compactness, and efficiency. Sun's Fast Infoset is a horrendous concoction that we can only hope never achieves any prominence. Leave it to the company who made Java the bloated mess it is today to come up with something like that!
Hey guys, here's a clue...before including an ever so nifty new compression / performance feature into your proposals, how about actually quantifying the expected benefits? This includes both performance of parsing as well as generation. Yes we need a binary XML standard, but keep it simple PLEASE.
Do you have proof? Because this is something I'm actually interested in, and no one I know has a beef with XML's performance and a proof to back up their claims.
Bottom line is that most XML parsers are crap. There are some good ones though (such as expat) but you can still do a lot better even with fairly simple binary encodings.
This is weak for the following reason:
The 'feature' of allowing numerous forgeries after the first packet is proved authentic is a weakness. All you need to do is intercept a packet, hold it and analyze it, forge your own message and send it first, then send the old packet, which will bounce as a forgery.
Typical slashdotter missing the idea completely. "Forgeries" are easily detectable by the intended recipient, so you you can't blindly "forge your own message" to fool the recipient.
The point is that even though the intended recipient can detect actual forgeries, the participants can plausibly claim to outside parties that any message they had exchanged was a forgery. Note that the only piece of digitally signed material is one input to a secure 2-party computation resulting in the session key.
While it might not matter all that much for standard entry level joe-programmer jobs, it most definitely matters in areas such as research and advanced development work. Take a look at the backgrounds of people who work for Google and any major research lab, for example. You will find a majority went to top-10 institutions.
If you can transfer to a better program, you should definitely do it. Not only does it improve your job prospects, you will probably learn more due to better teaching and resources. And don't underestimate the value of simply being around people of higher caliber.
Cross between Coral and BitTorrent?
on
P2P Through Firewalls
·
· Score: 3, Informative
This looks like an interesting hybrid of Coral and BitTorrent. Coral is nice in that you don't need to install any client-side software to take advantage of it. This one it appears you do need to install a client-side proxy, which is a little scary.
This system seems to utilize a client that takes on roles of both the BitTorrent tracker and the Coral caching nodes. I wonder how the client caches cooordinate? Any centralized server involved here?
Another firewall-busting HTTP serving system is YouServ (coral link), though geared more at sharing personal content instead of content requiring "super distribution".
It's times like this when you'd REALLY like the ability to mod the story itself as troll/flamebait!
At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and longevity of the vendor pushing it (forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby - Java could become the child nobody wants to talk about if Sun dies) - right now that's C# and the.NET Framework ---
I never receive OutOfMemoryError exceptions, and jvmstat (http://developers.sun.com/dev/coolstuff/jvmstat/) shows that the VM is collecting as it should (heap never grows, eden fills up, is collected, repeat).
It's not the heap leaking so it won't cause java out of memory, nor will it be detectable with a heap analysis tool. It's an internal JRE leak. Take a look at the RSS reported by "top" or "ps". It DOES grow consistently and will exceed the available memory if you let it run long enough. I'm using Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) and the 2.6.8-1.521smp kernel. Yes, I just tried it. Maybe fixed in _04 but I doubt it.
the response was either silence or "produce a small test case showing the problem
Even when producing a very small test case they do not necessarily acknowledge the problem. I submitted a 2-line test case to demonstrate a bug about a year ago (maybe even longer) and last I checked it has yet to hit the bug parade. If you're interested in seeing the test case, see my other post under this topic regarding memory leaks. It's about as simple as it gets.
Yes it should not ever leak memory (ignoring the issue of shoddy applications failing to clean up references to unused objects), but it does. Here's an example. Run this program under Linux, using any 1.4.* Java runtime. It grows and grows!
for (;;) { java.net.NetworkInterface.getNetworkInterfaces(); }
Sun's second-rate programmers have caused enormous problems for Java and its image. It would be much better off in other hands (ideally the open source community).
Re:Too many people trying to use p2p
on
P2P Web searches
·
· Score: 3, Insightful
True, at some point networks and machines will be so congested with various p2p protocals, that everyone will jump back to centralized servers.
If you'd take some time to actually read the article, you'd see that the story is about research that addresses congestion problems with existing p2p methods.
Besides, much if not most traffic from p2p networks is from file downloads, not query routing. Moving files to a centralized server isn't going to reduce that traffic at all. In fact, the bottlenecks that result can make congestion even worse.
Moving files to central servers only seems to help congestion because central servers with anything interesting to download tend to be shut down quickly.
another senseless Slashdot story title
on
P2P Web searches
·
· Score: 3, Interesting
This is some pretty cool research, but this really has pretty much nothing to do with the web.
It's an ariticle describing a new p2p query routing method. Nothing more. There's already a lot of such algorithms out there. This one seems to exhibit some nice completness properties that hold in idealized scale free networks. But I'm not convinced such a theoretical property would hold in the real world. While p2p networks tend to be roughly scale free, the "roughly" and "tend to be" qualifiers are what make such theoretical properties unlikely to hold in practice.
Nice to see they plan to release some software based on the technique though.
I believe there are couple of problems with this scheme.
1. The site owner will not be able to monitor hits on the site.
2. This appears to work for static pages but it won't work with dynamic pages ie. php
Add to this:
3. Malicious caching nodes could be doing nasty things like modifying requested content before serving it (such as inserting their own advertisements).
Still, it's a very nice system which still has plenty of applications despite such limitations.
This is very much the same concept as Akamai, only it exploits a dynamic set of hosts instead of Akamai's mostly fixed set of trusted servers.
Coral wouldn't be a good solution for serving critical web content since the caching nodes are untrusted and potentially malicious. They could do things like serve graphic porn images in place of your site. Techniques for quickly detecting and excluding such malicious nodes could make this rather unlikely in practice, but it's an issue that I believe will keep Akamai in business.
And since processors are supposed to double their speed every 18 months, I guess that cracking ability will follow the same trend. Scary...
Not really...nobody expects this trend in processing performance to continue forever. There are in fact provable limitations given things such as the number of atoms available in the universe that can be harnessed for computation... ignoring little details like quantum computation and such:-). These limitations may seem "out there" but in fact they aren't nearly as unrealistic as you might think. Exponentials grow FAST.
It's trivial to continue scaling the computing requirements required to break encryption schemes by simply adding more bits. That is, assuming the encryption/hash scheme itself doesn't have some fatal flaw which may allow for a sub-exponential cracking algorithm.
The bytecode is still the same in 1.5, but some of the language features use methods only available in 1.5. For instance: Auto(Un)Boxing uses the java.lang.Integer.toInt() Method that was introduced in 1.5....
Ah, OK, so it's not the JVM that's the issue with backwards compatability, but the lack of the appropriate library support. Interesting. I gather then that a 1.4 JVM would actually work just fine provided the 1.5 libraries were in its classpath.
I can't seem to find anything about this mysterious method "toInt()" in the 1.5 api specs, but I understand the issue now. Thanks.
...is that it sucks you in because it's free, but at the same time is closed source so that you have to beg some unresponsive god to fix bugs or add features.
Here here... finally some criticism of Java with actual merit.
Sun seriously needs to get their head out of their ass... submitting bugs has basically become a futile exercise. One bug I recently reported took 6 months to acknowledge, and the last one I submitted has gone completely ignored for even longer despite a simple 3 line program clearly demonstrating the issue. Now I don't even bother.
The only problem with Java is the fact that Sun controls it. If it were open, Swing and various other crappy & bloated aspects of Java (such as entire EJB spec) would likely have been abandoned long ago and replaced with sensible alternatives.
The GUI is poorly _emulated_ and does not even use the complete Win32 GUI subset, instead creates it's own litle API that you can apply themese to.
Hey dumbass... azureus uses SWT which is *entirely* based on native widgets. Emulated my ass.... Did you even try it? What app does use "the complete Win32 GUI subset" and why does it even matter? Yes I tried resizing it, I saw no "GUI inconsistencies". I somehow doubt you even tried it, or maybe you're just high?
1. Java does not have support for DNS in its main classes as recent as 1.4.x (need to look at 1.5). As such it is not suitable for any more complex network software period
Uhhh...wrong. Java has had support for domain name resolution (and reverse DNS lookup) since its inception! Sure it doesn't have ability to do fancier stuff like dynamic DNS updates in its main classes, but neither do any other mainstream languages. Languages such as C++ don't even have support for Sockets in their "main classes", so this is a rather weak criticism even if it were remotely true.
2. Java network interface support is not platform independent. As a result any application that needs to bind to a specific interface on a multihomed machine needs to have external config or to be platform dependant which largely defeats the idea of using java in first place.
Wrong again! It's trivial to iterate over the set of network interfaces on a machine and bind to a specific one. One of my apps uses this functionality, and it works perfectly on multiple platforms (including linux, mac, pc, aix,...)
Slashdot Mirror
An apologist is one who argues in defense of something, in this case the person is arguing in defense of Microsoft's shoddy security practices. Not sure why you're bringing monopolistic practices into this.
For the most part, you'll be fine as long as you exercise some clue. Keep up to date on OS and application patches, run a good antivirus program, stay behind a firewall, and don't use insecure software (such as IE/Outlook); ...
Yeah no shit. But why should anyone have to jump through these hoops? It might not be a big deal for you, but if you look at the evidence, this is a HUGE issue for most of the population. As a slashdot reading geek, you of all people should have higher expectations of the software you use.By the way - your analogy was terrible.
Glad you liked it. It was intended to be a touch ridiculous, just like the parent's.
Right, OTHER COMPUTERS all infected due to Microsoft security flaws. It was infected because the software installed on it DOESN'T WORK like it should. I find it remarkable that people have such low expectations of software that they are willing to defend such a situation by blaming the user. Not everyone is a slashdot reading geek (for which we should be extremely grateful.)
The original analogy that compared that to someone else hitting your car is accurate.Maybe, if within 4 minutes of pulling out of the driveway and parking beside the curb on a safe street, you could expect to get hit by dozens of cars because you forgot to purchase and install the extra bonus safety reflectors that the dealer neglected to tell you about. Try again.
Not a very accurate analogy. Wouldn't it suck if the car were to unconditionally burst into flames unless you were sure to also purchase an extra $1000 in "safety features" and have them installed perfectly before ever attempting to drive it? (And without the dealer actually telling you this.)
Get it now? You microsoft apologists should really get a clue.
"binary xml" is simply a shorter way of saying something like "binary serialization of the XML infoset". The binary XML guys like to be concise and compact in their terminology in addition to their representations :-)
The question should instead be "How can we best standardize binary XML?"
My main fear is the typical "design by committee" style of standards bodies will lead to a super-bloated binary standard containing every pet feature of each participant. This could make it just as slow and painful as working with any textual encoding. I think Mike Conner's "CBXML" is probably the right mix of simplicity, compactness, and efficiency. Sun's Fast Infoset is a horrendous concoction that we can only hope never achieves any prominence. Leave it to the company who made Java the bloated mess it is today to come up with something like that!
Hey guys, here's a clue...before including an ever so nifty new compression / performance feature into your proposals, how about actually quantifying the expected benefits? This includes both performance of parsing as well as generation. Yes we need a binary XML standard, but keep it simple PLEASE.
try this
Bottom line is that most XML parsers are crap. There are some good ones though (such as expat) but you can still do a lot better even with fairly simple binary encodings.
I run YouServ, a hybrid web-based p2p system, within IBM. It is used by thousands for work-oriented content sharing.
Typical slashdotter missing the idea completely. "Forgeries" are easily detectable by the intended recipient, so you you can't blindly "forge your own message" to fool the recipient.
The point is that even though the intended recipient can detect actual forgeries, the participants can plausibly claim to outside parties that any message they had exchanged was a forgery. Note that the only piece of digitally signed material is one input to a secure 2-party computation resulting in the session key.
the idea is sound.
While it might not matter all that much for standard entry level joe-programmer jobs, it most definitely matters in areas such as research and advanced development work. Take a look at the backgrounds of people who work for Google and any major research lab, for example. You will find a majority went to top-10 institutions.
If you can transfer to a better program, you should definitely do it. Not only does it improve your job prospects, you will probably learn more due to better teaching and resources. And don't underestimate the value of simply being around people of higher caliber.
This looks like an interesting hybrid of Coral and BitTorrent. Coral is nice in that you don't need to install any client-side software to take advantage of it. This one it appears you do need to install a client-side proxy, which is a little scary.
This system seems to utilize a client that takes on roles of both the BitTorrent tracker and the Coral caching nodes. I wonder how the client caches cooordinate? Any centralized server involved here?
Another firewall-busting HTTP serving system is YouServ (coral link), though geared more at sharing personal content instead of content requiring "super distribution".
I guess you don't know anyone who works for google!
At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and longevity of the vendor pushing it (forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby - Java could become the child nobody wants to talk about if Sun dies) - right now that's C# and the .NET Framework ---
It's not the heap leaking so it won't cause java out of memory, nor will it be detectable with a heap analysis tool. It's an internal JRE leak. Take a look at the RSS reported by "top" or "ps". It DOES grow consistently and will exceed the available memory if you let it run long enough. I'm using Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) and the 2.6.8-1.521smp kernel. Yes, I just tried it.
Maybe fixed in _04 but I doubt it.
Even when producing a very small test case they do not necessarily acknowledge the problem. I submitted a 2-line test case to demonstrate a bug about a year ago (maybe even longer) and last I checked it has yet to hit the bug parade. If you're interested in seeing the test case, see my other post under this topic regarding memory leaks. It's about as simple as it gets.
Just another example of how Sun is killing Java.
Yes it should not ever leak memory (ignoring the issue of shoddy applications failing to clean up references to unused objects), but it does. Here's an example. Run this program under Linux, using any 1.4.* Java runtime. It grows and grows!
for (;;) { java.net.NetworkInterface.getNetworkInterfaces(); }
Sun's second-rate programmers have caused enormous problems for Java and its image. It would be much better off in other hands (ideally the open source community).
If you'd take some time to actually read the article, you'd see that the story is about research that addresses congestion problems with existing p2p methods.
Besides, much if not most traffic from p2p networks is from file downloads, not query routing. Moving files to a centralized server isn't going to reduce that traffic at all. In fact, the bottlenecks that result can make congestion even worse.
Moving files to central servers only seems to help congestion because central servers with anything interesting to download tend to be shut down quickly.
It's an ariticle describing a new p2p query routing method. Nothing more. There's already a lot of such algorithms out there. This one seems to exhibit some nice completness properties that hold in idealized scale free networks. But I'm not convinced such a theoretical property would hold in the real world. While p2p networks tend to be roughly scale free, the "roughly" and "tend to be" qualifiers are what make such theoretical properties unlikely to hold in practice.
Nice to see they plan to release some software based on the technique though.
1. The site owner will not be able to monitor hits on the site.
2. This appears to work for static pages but it won't work with dynamic pages ie. php
Add to this:
3. Malicious caching nodes could be doing nasty things like modifying requested content before serving it (such as inserting their own advertisements).
Still, it's a very nice system which still has plenty of applications despite such limitations.Coral wouldn't be a good solution for serving critical web content since the caching nodes are untrusted and potentially malicious. They could do things like serve graphic porn images in place of your site. Techniques for quickly detecting and excluding such malicious nodes could make this rather unlikely in practice, but it's an issue that I believe will keep Akamai in business.
Not really...nobody expects this trend in processing performance to continue forever. There are in fact provable limitations given things such as the number of atoms available in the universe that can be harnessed for computation... ignoring little details like quantum computation and such :-). These limitations may seem "out there" but in fact they aren't nearly as unrealistic as you might think. Exponentials grow FAST.
It's trivial to continue scaling the computing requirements required to break encryption schemes by simply adding more bits. That is, assuming the encryption/hash scheme itself doesn't have some fatal flaw which may allow for a sub-exponential cracking algorithm.
Agreed. In general "whitepaper" == "vacuous proposal".
Editors, you can do much better...
Ah, OK, so it's not the JVM that's the issue with backwards compatability, but the lack of the appropriate library support. Interesting. I gather then that a 1.4 JVM would actually work just fine provided the 1.5 libraries were in its classpath.
I can't seem to find anything about this mysterious method "toInt()" in the 1.5 api specs, but I understand the issue now. Thanks.
Here here... finally some criticism of Java with actual merit.
Sun seriously needs to get their head out of their ass... submitting bugs has basically become a futile exercise. One bug I recently reported took 6 months to acknowledge, and the last one I submitted has gone completely ignored for even longer despite a simple 3 line program clearly demonstrating the issue. Now I don't even bother.
The only problem with Java is the fact that Sun controls it. If it were open, Swing and various other crappy & bloated aspects of Java (such as entire EJB spec) would likely have been abandoned long ago and replaced with sensible alternatives.
Hey dumbass... azureus uses SWT which is *entirely* based on native widgets. Emulated my ass.... Did you even try it? What app does use "the complete Win32 GUI subset" and why does it even matter? Yes I tried resizing it, I saw no "GUI inconsistencies". I somehow doubt you even tried it, or maybe you're just high?
Uhhh...wrong. Java has had support for domain name resolution (and reverse DNS lookup) since its inception! Sure it doesn't have ability to do fancier stuff like dynamic DNS updates in its main classes, but neither do any other mainstream languages. Languages such as C++ don't even have support for Sockets in their "main classes", so this is a rather weak criticism even if it were remotely true.
2. Java network interface support is not platform independent. As a result any application that needs to bind to a specific interface on a multihomed machine needs to have external config or to be platform dependant which largely defeats the idea of using java in first place.
Wrong again! It's trivial to iterate over the set of network interfaces on a machine and bind to a specific one. One of my apps uses this functionality, and it works perfectly on multiple platforms (including linux, mac, pc, aix, ...)
Try again cluesink...