Of course, given that I have a gig of RAM in this machine, and that RAM goes for a little more per 512MB stick than I spend on a typical Saturday night out, it really doesn't matter to me at all.
It's nice to know you're so well disposed, other than that I fail to see the point of your reply.
Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.
Everything is easy when you approach it from the point of view that it doesn't actually have to work.
There are many versions of the Java environment, from different vendors, all with subtly different behaviors and ways of integrating into the environment. Not to mention that the user may be running other Java applications which depend on a particular version of the Java environment, which further complicates matters. This makes it a pain if you want to deliver an application to the user with minimal hassle.
Or, you can just mandate that the user run such-and-such version of the Java enviroment on such-and-such platform, but then you lose a large part of the write-once, run-everywhere appeal.
I run Java on very low spec embedded PC's, and it's no slouch there. Even if there is a couple of seconds wait at startup, the JIT compiler means a well written app will run without being appreciably slower than a "native" app once the JVM is bootstrapped.
Java's "slowness" has at least three components: startup time, garbage collection delays, and the huge footprint which triggers swap activity.
For server applications, none of these matter much. For interactive client applications, these factors conspire to make Java apps look very bad when compared to "native" competitors. The exception here are applications like Eclipse, which you start when you get in from work and don't quit until you're done. But for most other apps, e.g. utility apps which you just want to quickly use and close, or workflows where you switch between multiple apps frequently, Java is just not suited.
Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.
You're missing the point royally. Java isn't slow at doing grunt work. Few people would contest that. But as a platform to write desktop applications, it is a pig. The Swing UI is slow and prone to memory leaks, data interchange facilities are poor (even the clipboard functionality integrates poorly with the surrounding environment), memory requirements are completely uncontrollable.
Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.
Indeed, and that's why most Java shops pretty much only run one application on their servers.
This could be rephraed as "bad Java programmers leak memory".
The fundamental problem is that you cannot control how memory gets used. For example: the JVM allocates memory from the underlying OS in chunks which it then doles out to your app as necessary. Then at garbage collection time, the memory is reclaimed from your app and returned to the JVM. But then the JVM may or may not ever return this memory to the underlying OS. This means that even if you have a tiny application, when the user opens a mammoth 100MB document just once, the application will continue using 100MB even after the user has closed the document.
Yes, this is sort of tunable through commandline options and other properties, but then only for some versions of some implementations of the JVM. Which brings us back to the first point, that it's a hassle to deliver hassle-free Java applications. It's so troublesome in fact that some programmers choose to simply distribute a JVM along with their apps.
The bottomline is this: Java is a cool language, but it just doesn't play nice with others. It insists on reinventing everything, it insists on abstracting everything, and it insists on total control over the environment. That's fine for in-house apps or web apps, but it limits Java's adoption on the desktop.
And ultimately, I think it condemns Java to a perpetual "behind the scenes" existance, growing ever more baroque appendages in its invisible niche, until its burdensome legacy is swept away by something more open.
Well, as the anonymous poster above already mentioned, you need to consider what came out of Microsoft before.NET; a confused jumble of acronyms and paradigms with the combined lifespan of a Coke bottle.
.NET really is Microsoft's first serious contribution to the computing culture (as opposed to industry) at large. It synthesises many of the ideas of the past decade in a very clean and logical way. And it's remarkably open: not in the sense that it's endorsed by some standards body, but in the sense that it actually makes an effort to integrate with other technologies -- through the pervasive use of XML, the Common Language Runtime and the numerous hooks in the class library, all the way down to the fact that the C# compiler will actually not explode when encountering a file with \n line termination rather than \r\n.
.NET is a heavy-duty framework that will be around in some form for decades to come, and it's pretty good. It's like Java but less insular, it's like C but less tedious.
What generates all the hubbub, of course, is that something like this is coming from Microsoft. Think of it as a celebration party. What's being celebrated is that Microsoft is finally coming of age.
I saw some patches coming by on the mplayer-dev mailing list that purportedly implement seeking for Real streams, but I don't know if they ever made it in and/or how reliable they are. Other than that there are sync problems (as the other poster mentioned), connection problems (with rtsp:// in particular, yes, the live.com libs sorta work, no, sorta isn't good enough), stability problems, and assorted minor brokennesses.
I love mplayer but of all the formats it supports, Real is perhaps the worst.
RealPlayer 10 doesn't ask for your email address anymore. I just installed it. It looks decent enough.
Also support for playing Real media formats in Xine/mplayer still isn't quite as reliable as the real thing. Not to mention the browser plugin support. Finally Xine/mplayer can be a bitch to install.
I like what Real's doing. RealPlayer 10 is like the RealPlayer 1.0 that never was.
Not more - not less. All that portknocking does is shifting the security to a layer where it doesn't belong.
Yes, but that's exactly the point. Portknocking is a steganographic application: it doesn't protect the message, but hides the existence of the message. It does so precisely because it interferes at a layer where it doesn't belong.
And even if you don't want others to see that there are services running on your host there are better solutions. e.g. sending a special string to some UDP port.
No, because having a server listen on a UDP port clearly signals the expectation of meaningful communication. The equivalent of portknocking would be a server that listens on a UDP port, but rather than looking at the string it receives, looks at (say) the delay between each byte received. Obviously network delays and other uncontrollable factors make this impractical.
If someone can sniff your traffic and he knows about portknocking it's trivial for him to detect it. If someone can't sniff your traffic there's no advantage in using portknocking.
It's not that simple. Even if somebody can sniff traffic in principle, he can't sniff everybody's traffic all the time. He has to evaluate which targets are likely to yield anything of value. Since a system protected by portknocking does not give him any clues of what he can expect to find, why would he sniff your traffic?
This is like saying that mathematics should be replaced by English. Or that first order logic should be replaced by English.
The whole point is to abstract away from human languages. You lose expressiveness in the process, but you gain the ability to reason rigorously about statements, which leads directly to the possibility of automation.
We can either just keep using the rules of maths and logic and replace the symbols by English words. This gets you something like COBOL. Or we can use some dialect of English, but drastically restrict the scope of applicability. Then you get rule-based expert like systems that can answer questions about a very limited domain. Neither yields anything like the "mechanical slave" you seem to envision.
Arguably the two biggest problems today are spam and trojans. Both of these stem from what is essentially a security failure, namely the abuse of authority. In the case of spam, the spammer is erroneously granted the authority to send out millions of emails. In the case of trojans, a piece of code fools the user into granting it the authority to run.
Neither of these problems is solved by using managed code environments.
Yes, Java solves a number of annoying problems. But it does so at significant expense, and the problems it solves are exactly those problems that are trivial to fix when found. It does not, and can not, fix the much more prevalent and potentially much more disruptive problems that occur at the human level.
Only unrelenting vigilance and diligence during development and deployment can ever hope to solve those problems.
Child molesters aren't necessarily mentally ill. The mere desire to harm somebody, much less have sex with a child, is not indicative of mental illness.
It's exactly the other way around. You consider them mentally ill because they are demonized. The whole point of demonization is to reinforce the taboo and the social stigma. The idea is that the prospective child molesters internalize this societal pressure to such an extent that they do not act on their desires.
Research like this is useful for the propagandist/advocate.
Even though it completely fails to address issues such as startup time, runtime linking cost, and such minor nits as gc and compilation delays, as well as the way all these things interact as applications grow, not to mention as memory use, it does show that Java can do a mean synthetic benchmark -- and lacking pretty much everything else, that's all the propagandists really have.
Most people will (or should) recognize however, that this is a lot like saying, "hash tables are faster than arrays!", without specifying the operation, the hash function, or the data set.
This process is still young, but the eventual direction this will take is 3d apps over PHP and the web.
No, for the simple fact that this project is not headed in that direction. It does not provide for 3D apps over the web.
It's bound to go that way.
No, because in order for it to go that way, a terrible amount of work would need to be done, and the end result wouldn't provide anything that doesn't already exist.
I think it's extremely viable for a plugin to be designed that will use this, and many will adopt it for websites as a result. Why the hell wouldn't they?
Because PHP is not very well suited to the task, and better solutions exist. This hack is on the order of building a toilet out of LEGO's. Possible, but neither viable nor a harbringer of things to come.
It's not a totally bad idea, just one that scares me somewhat, if it's used maliciously.
I don't know that you know what the idea is here.
There are systemic misuses and outright exploits. I am sure that any new system has both.
There is nothing new about this "system". It's just another computer program.
It can't be used "over the net". Conceivably somebody could write a plug-in that allows people to run PHP in a webbrowser, as well as some bindings to the necessary OpenGL libraries, but that is possible for any language.
That's the crux of my arguement: yes, this project appears harmless, but it could be manipulated maliciously.
No, it could not.
It's still to early to tell how far it could go
Not at all. It won't go anywhere.
but it's bad practice to create systems for content delivery that impose intense graphical CPU/GPU usage, without any standards of conformity, or checks and balances.
He didn't create a "system for content delivery". He just wrote an app that uses OpenGL. That he used PHP to write the app is irrelevant apart from the novelty factor.
Actually the real problem is that the kernel will sometimes grant memory requests that it cannot fulfill. So it can happen that malloc() returns a block of memory to the application, but as soon as the application tries to use the allocated memory, the kernel kills it, since the memory just isn't there. Allegedly this can be fixed/tuned via/proc/sys/vm/overcommit_memory, but it's hit-and-miss really. The accounting is just not reliable.
There are lots of options. I don't know how feasible those options are - but they havn't really been tried to any great extent. There's nothing equivalent in the microkernel area to the extensively tested and tweaked freely developed Linux.
There has been at least one port of Linux to Mach, MkLinux. This port actually had some support from Apple. You can slice the numbers any way you want; it's slow.
Is that because of lack of effort? Inherent difficulty? Mach flaws? Who can tell? What we do know is that almost no microkernel based designs survived in the wild. At what point does it stop being an implementation problem and become a design problem?
About modularization, I disagree with you. The problems you are describing stem from over-engineering. Modular systems don't need to be hard to understand or work with.
All I'm saying is that it's harder to write modular code than to write non-modular code. You may have a point about the overengineering.
I think they are. A 10% hit in performance is going to get eaten up as hardware gets better and faster. But that 50% increase in manageability and flexibility is going to pay dividends well into the future.
It's important to point out that it's not so clear-cut as a 10% performance hit. The hit might be 1000% here and just 0.5% somewhere else, or it might be that the modularization prevents the use of a particularly efficient algorithm. The overall performance hit on average might be 10%, but on the whole that's a pretty useless figure.
Secondly, the increased manageability has a large subjective component. There's a huge learning curve to overcome when you modify highly modular systems. It's a lot easier to just add a member to a struct and add a few lines of code here and there. For the increased manageability to actually materialize you really need lots of people with lots of training and experience to be working on a huge codebase. With F/OSS, that's usually not the case.
Macs have always been quite hard to emulate, at least that's my understanding. Thanks to Altivec, register starvation, and other things (see another post of mine in this topic) it's not easy.
The more probable reason is that demand for a Mac emulator is very small. There's little need to postulate magical, unemulatable CPU capabilities. Nobody had any problems emulating 68K, even though those chips are very different from x86.
The odds that any node fails increase dramatically as you add more nodes. With your proposal you can't even skip a block on temporary node failure, since you don't know the order of the blocks.
Excellent. It's about time Microsoft started making lasting contributions to the computing culture at large. Rather than releasing huge blobby tur(n)key "solutions" which become obsolete every few years they're beginning to actually release well-designed, extensible stuff with decent shelf-life, and they're actually working with other people to do so (ECMA, now SourceForge...). Bravo Microsoft, welcome to the party! Maybe in 5 to 10 years time the Windows developer culture will be as rich and interesting as the GNU/Linux and *NIX cultures.
Slashdot Mirror
The point is that you can't tell users who complain about the memory use of your app that Tim C thinks it's alright.
Of course, given that I have a gig of RAM in this machine, and that RAM goes for a little more per 512MB stick than I spend on a typical Saturday night out, it really doesn't matter to me at all.
It's nice to know you're so well disposed, other than that I fail to see the point of your reply.
Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.
Everything is easy when you approach it from the point of view that it doesn't actually have to work.
There are many versions of the Java environment, from different vendors, all with subtly different behaviors and ways of integrating into the environment. Not to mention that the user may be running other Java applications which depend on a particular version of the Java environment, which further complicates matters. This makes it a pain if you want to deliver an application to the user with minimal hassle.
Or, you can just mandate that the user run such-and-such version of the Java enviroment on such-and-such platform, but then you lose a large part of the write-once, run-everywhere appeal.
I run Java on very low spec embedded PC's, and it's no slouch there. Even if there is a couple of seconds wait at startup, the JIT compiler means a well written app will run without being appreciably slower than a "native" app once the JVM is bootstrapped.
Java's "slowness" has at least three components: startup time, garbage collection delays, and the huge footprint which triggers swap activity.
For server applications, none of these matter much. For interactive client applications, these factors conspire to make Java apps look very bad when compared to "native" competitors. The exception here are applications like Eclipse, which you start when you get in from work and don't quit until you're done. But for most other apps, e.g. utility apps which you just want to quickly use and close, or workflows where you switch between multiple apps frequently, Java is just not suited.
Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.
You're missing the point royally. Java isn't slow at doing grunt work. Few people would contest that. But as a platform to write desktop applications, it is a pig. The Swing UI is slow and prone to memory leaks, data interchange facilities are poor (even the clipboard functionality integrates poorly with the surrounding environment), memory requirements are completely uncontrollable.
Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.
Indeed, and that's why most Java shops pretty much only run one application on their servers.
This could be rephraed as "bad Java programmers leak memory".
The fundamental problem is that you cannot control how memory gets used. For example: the JVM allocates memory from the underlying OS in chunks which it then doles out to your app as necessary. Then at garbage collection time, the memory is reclaimed from your app and returned to the JVM. But then the JVM may or may not ever return this memory to the underlying OS. This means that even if you have a tiny application, when the user opens a mammoth 100MB document just once, the application will continue using 100MB even after the user has closed the document.
Yes, this is sort of tunable through commandline options and other properties, but then only for some versions of some implementations of the JVM. Which brings us back to the first point, that it's a hassle to deliver hassle-free Java applications. It's so troublesome in fact that some programmers choose to simply distribute a JVM along with their apps.
The bottomline is this: Java is a cool language, but it just doesn't play nice with others. It insists on reinventing everything, it insists on abstracting everything, and it insists on total control over the environment. That's fine for in-house apps or web apps, but it limits Java's adoption on the desktop.
And ultimately, I think it condemns Java to a perpetual "behind the scenes" existance, growing ever more baroque appendages in its invisible niche, until its burdensome legacy is swept away by something more open.
What generates all the hubbub, of course, is that something like this is coming from Microsoft. Think of it as a celebration party. What's being celebrated is that Microsoft is finally coming of age.
Yes, it supports fullscreen playback. It isn't as fast and clever as, say, mplayer, but it's there and it works.
Works for me, Firefox 0.9 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9).
I saw some patches coming by on the mplayer-dev mailing list that purportedly implement seeking for Real streams, but I don't know if they ever made it in and/or how reliable they are. Other than that there are sync problems (as the other poster mentioned), connection problems (with rtsp:// in particular, yes, the live.com libs sorta work, no, sorta isn't good enough), stability problems, and assorted minor brokennesses.
I love mplayer but of all the formats it supports, Real is perhaps the worst.
RealPlayer 10 doesn't ask for your email address anymore. I just installed it. It looks decent enough.
Also support for playing Real media formats in Xine/mplayer still isn't quite as reliable as the real thing. Not to mention the browser plugin support. Finally Xine/mplayer can be a bitch to install.
I like what Real's doing. RealPlayer 10 is like the RealPlayer 1.0 that never was.
Not more - not less. All that portknocking does is shifting the security to a layer where it doesn't belong.
Yes, but that's exactly the point. Portknocking is a steganographic application: it doesn't protect the message, but hides the existence of the message. It does so precisely because it interferes at a layer where it doesn't belong.
And even if you don't want others to see that there are services running on your host there are better solutions. e.g. sending a special string to some UDP port.
No, because having a server listen on a UDP port clearly signals the expectation of meaningful communication. The equivalent of portknocking would be a server that listens on a UDP port, but rather than looking at the string it receives, looks at (say) the delay between each byte received. Obviously network delays and other uncontrollable factors make this impractical.
If someone can sniff your traffic and he knows about portknocking it's trivial for him to detect it. If someone can't sniff your traffic there's no advantage in using portknocking.
It's not that simple. Even if somebody can sniff traffic in principle, he can't sniff everybody's traffic all the time. He has to evaluate which targets are likely to yield anything of value. Since a system protected by portknocking does not give him any clues of what he can expect to find, why would he sniff your traffic?
Free trade means that no one gets excluded.
Urr, no, that's communism. (or what you Americans would probably call socialism)
Free trade excludes everyone who is, in the broadest sense of the word, unfit.
This is like saying that mathematics should be replaced by English. Or that first order logic should be replaced by English.
The whole point is to abstract away from human languages. You lose expressiveness in the process, but you gain the ability to reason rigorously about statements, which leads directly to the possibility of automation.
We can either just keep using the rules of maths and logic and replace the symbols by English words. This gets you something like COBOL. Or we can use some dialect of English, but drastically restrict the scope of applicability. Then you get rule-based expert like systems that can answer questions about a very limited domain. Neither yields anything like the "mechanical slave" you seem to envision.
Arguably the two biggest problems today are spam and trojans. Both of these stem from what is essentially a security failure, namely the abuse of authority. In the case of spam, the spammer is erroneously granted the authority to send out millions of emails. In the case of trojans, a piece of code fools the user into granting it the authority to run.
Neither of these problems is solved by using managed code environments.
Yes, Java solves a number of annoying problems. But it does so at significant expense, and the problems it solves are exactly those problems that are trivial to fix when found. It does not, and can not, fix the much more prevalent and potentially much more disruptive problems that occur at the human level.
Only unrelenting vigilance and diligence during development and deployment can ever hope to solve those problems.
I love it. It plays everything. On whatever.
Child molesters aren't necessarily mentally ill. The mere desire to harm somebody, much less have sex with a child, is not indicative of mental illness.
It's exactly the other way around. You consider them mentally ill because they are demonized. The whole point of demonization is to reinforce the taboo and the social stigma. The idea is that the prospective child molesters internalize this societal pressure to such an extent that they do not act on their desires.
Research like this is useful for the propagandist/advocate.
Even though it completely fails to address issues such as startup time, runtime linking cost, and such minor nits as gc and compilation delays, as well as the way all these things interact as applications grow, not to mention as memory use, it does show that Java can do a mean synthetic benchmark -- and lacking pretty much everything else, that's all the propagandists really have.
Most people will (or should) recognize however, that this is a lot like saying, "hash tables are faster than arrays!", without specifying the operation, the hash function, or the data set.
This process is still young, but the eventual direction this will take is 3d apps over PHP and the web.
No, for the simple fact that this project is not headed in that direction. It does not provide for 3D apps over the web.
It's bound to go that way.
No, because in order for it to go that way, a terrible amount of work would need to be done, and the end result wouldn't provide anything that doesn't already exist.
I think it's extremely viable for a plugin to be designed that will use this, and many will adopt it for websites as a result. Why the hell wouldn't they?
Because PHP is not very well suited to the task, and better solutions exist. This hack is on the order of building a toilet out of LEGO's. Possible, but neither viable nor a harbringer of things to come.
It's not a totally bad idea, just one that scares me somewhat, if it's used maliciously.
I don't know that you know what the idea is here.
There are systemic misuses and outright exploits. I am sure that any new system has both.
There is nothing new about this "system". It's just another computer program.
And Flash differs how?
In pretty much every way.
And who controls how this is used over the net?
It can't be used "over the net". Conceivably somebody could write a plug-in that allows people to run PHP in a webbrowser, as well as some bindings to the necessary OpenGL libraries, but that is possible for any language.
That's the crux of my arguement: yes, this project appears harmless, but it could be manipulated maliciously.
No, it could not.
It's still to early to tell how far it could go
Not at all. It won't go anywhere.
but it's bad practice to create systems for content delivery that impose intense graphical CPU/GPU usage, without any standards of conformity, or checks and balances.
He didn't create a "system for content delivery". He just wrote an app that uses OpenGL. That he used PHP to write the app is irrelevant apart from the novelty factor.
You can manually type in filenames. Your rant is pointless.
Actually the real problem is that the kernel will sometimes grant memory requests that it cannot fulfill. So it can happen that malloc() returns a block of memory to the application, but as soon as the application tries to use the allocated memory, the kernel kills it, since the memory just isn't there. Allegedly this can be fixed/tuned via /proc/sys/vm/overcommit_memory, but it's hit-and-miss really. The accounting is just not reliable.
There are lots of options. I don't know how feasible those options are - but they havn't really been tried to any great extent. There's nothing equivalent in the microkernel area to the extensively tested and tweaked freely developed Linux.
There has been at least one port of Linux to Mach, MkLinux. This port actually had some support from Apple. You can slice the numbers any way you want; it's slow.
Is that because of lack of effort? Inherent difficulty? Mach flaws? Who can tell? What we do know is that almost no microkernel based designs survived in the wild. At what point does it stop being an implementation problem and become a design problem?
About modularization, I disagree with you. The problems you are describing stem from over-engineering. Modular systems don't need to be hard to understand or work with.
All I'm saying is that it's harder to write modular code than to write non-modular code. You may have a point about the overengineering.
I think they are. A 10% hit in performance is going to get eaten up as hardware gets better and faster. But that 50% increase in manageability and flexibility is going to pay dividends well into the future.
It's important to point out that it's not so clear-cut as a 10% performance hit. The hit might be 1000% here and just 0.5% somewhere else, or it might be that the modularization prevents the use of a particularly efficient algorithm. The overall performance hit on average might be 10%, but on the whole that's a pretty useless figure.
Secondly, the increased manageability has a large subjective component. There's a huge learning curve to overcome when you modify highly modular systems. It's a lot easier to just add a member to a struct and add a few lines of code here and there. For the increased manageability to actually materialize you really need lots of people with lots of training and experience to be working on a huge codebase. With F/OSS, that's usually not the case.
Macs have always been quite hard to emulate, at least that's my understanding. Thanks to Altivec, register starvation, and other things (see another post of mine in this topic) it's not easy.
The more probable reason is that demand for a Mac emulator is very small. There's little need to postulate magical, unemulatable CPU capabilities. Nobody had any problems emulating 68K, even though those chips are very different from x86.
The odds that any node fails increase dramatically as you add more nodes. With your proposal you can't even skip a block on temporary node failure, since you don't know the order of the blocks.
Seems to me like it would perform horribly.
Excellent. It's about time Microsoft started making lasting contributions to the computing culture at large. Rather than releasing huge blobby tur(n)key "solutions" which become obsolete every few years they're beginning to actually release well-designed, extensible stuff with decent shelf-life, and they're actually working with other people to do so (ECMA, now SourceForge...). Bravo Microsoft, welcome to the party! Maybe in 5 to 10 years time the Windows developer culture will be as rich and interesting as the GNU/Linux and *NIX cultures.
Did you even try something simple as typing "kernel vulnerability" in msdn.microsoft.com?
Does it mean anything? No.