I consider bugs that can only cause a DoS much less bad than bugs which can cause the machine to be compromised. If you DoS a machine, you can't then use it to DoS others, but if you compromise a machine, you *can* use it to compromise others. You can't write a worm using only DoS attacks, you must be able to execute code on the target machines.
As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the file system (ever tried setting creation dates on a file? ownership?).
What on earth do these two things have to do with Java's buffer overflow protection? If these things are hard to do in Java, that's because the APIs are badly designed, not because the language itself is secure. These are two totally different issues. It may be the case that Java's APIs are badly designed, but libraries can be replaced.
A SSH server written in Java will have zero buffer overflows.
By which I mean, of course, "A SSH server written in Java will have zero buffer overflows that allow you to execute arbitrary code." I'm well aware that Java doesn't prevent DoS attacks. In fact, a Java server would probably be more prone to DoS attacks for several reasons. I consider this a reasonable price to pay for making it impossible to compromise the machine with arbitrary code, which can be much worse than a DoS.
All of the security holes in that paper are holes in the sandbox that Sun has constructed for running *untrusted* code such as applets. They have absolutely no relevance to trusted code, such as a server you are running on your machine. Yes, the JVM is written in C, but how many buffer overflows do you see in Sun's JVM? I've never even heard of one. Safely executing a well-defined series of bytecodes prepared in advance by a compiler whose job is to output correct instruction sequences is an easier problem than safely accepting arbitrary malicious input from a network connection.
Dude. Cyclone looks totally awesome. C, but with modern saftey features? And with ML-style datatypes and pattern matching? If they would just add type inference and a very simple object system, this language might just be the most perfect language ever. Are there any downsides?
Time and time again, it has been proven that software written in C will be insecure. If you don't take extraordinary precautions which are far too inconvenient for most programmers to accept, you *will* have security holes in a network service written in C. And if you do take those precautions, they will interfere with the goal of providing a feature-rich, modern, up-to-date piece of software. Why oh why hasn't there been a move toward writing network services in languages which make most common kinds of security holes impossible? A SSH server written in Java will have zero buffer overflows. Nada. Zilch. It won't have any double-free bugs, or stack-smashing attacks of any kind. That way, developers can focus on fixing the logic bugs and implementing new features.
It's very easy to understand. If you write your server in a language that prevents several common sources of root exploits, then the number of root exploits present in your code will be dramatically reduced. I would definitely be willing to put up with a server that was twice as slow if it had no possibility of buffer overflows, ever.
That's why you get the kind of card that extends outside the computer and has a jack built in. Those dongles are worthless and anyone who buys one is just asking to buy a new network card in a year.
You're forgetting something: there are so many batteries, and they are so heavy, that they make up a significant portion of the weight of the entire car. Ever lifted a regular car battery? They are *really* heavy, and they're not even enough to power a car a half a mile. Us push-button Americans aren't going to be getting out of our cars to lug packs and packs of heavy batteries around. You would definitely need full-service stations for this. So it would cost more, plus it would probably take longer. Also, usually the batteries are in a very hard to access place (like underneath the passenger compartment or something) because they take up so much room. You'd have to give up your entire trunk just to store the batteries in an accessible place.
A super-breakthrough in battery technology that reduced both the size and weight of batteries by a factor of 10 might make this system reasonable. But at that point, your car could go 2000 miles on a single charge by putting 10 times the batteries in, which would take the same room and weigh the same as the batteries of today. At that point, it's better to just recharge the car overnight instead of worrying about swapping batteries.
This is not a problem that should be solved by work for hire. If what you want is protection for people whose photos are taken, then you should think about how to provide that instead of using a totally different legal concept. What if someone you didn't hire takes an unflattering picture of you? You're just as screwed even with work for hire. Instead, the people whose pictures are taken should have joint ownership of the copyright with the photographer. If the photographer wants to distribute the photos then, he'll have to get a model release form saying that you approve of distribution by him.
My point is that Fortran 95 is going about this the wrong way. They are adding all sorts of special-case optimizations to the core language. This makes the compiler more complex and harder to develop. There isn't even a free compiler for Fortran 95. If a new technique is discovered, for example this "Hilbert space-filling curve" for array traversal, you have to modify the compiler itself in order to implement it. OTOH, in C++ land, you simply change the library, or use a different library suited for a different task. Since the barrier to implementing new things like this is much lower, more experimentation can go on and more novel algorithms can be tried and used, which often gives more of a speedup than just optimizing throughput of old algorithms.
There's no way a meta-template could ever out perform that because the level of hinting is so much higher in the the fortran 95 syntax
I disagree with that statement. Unfortunately, you didn't provide any evidence for me to dispute. Why do you believe that?
Another Fortran apologist? I had no idea you guys were so common;-)
Did you even read the linked article? This statement beats optimized Fortran. Why? It uses a novel algorithm to traverse the 3D arrays that maximizes cache hits. To implement this in Fortran, you'd have to rewrite the compiler. In C++, this is simply a library feature. That's the difference. It's much easier to change a library than a compiler, so development of new features can happen much faster in a language that relies on libraries than in a language that puts major language features in the compiler itself. Faster development means more cool features to play with, and more time to optimize them. So much for your "language intrinsic will always beat a template" argument.
Discussion about the perfect copyright law can still be useful even if it doesn't directly apply to the US. There are plenty of other countries in the world, and in the future more will be created. If they have a better idea about the what the ideal copyright system would look like, they can model their systems after it instead of reusing the US model. And if the US is still around at that hypothetical time when other countries are using this new copyright model, then maybe it will be more receptive to changing its own model.
What are you talking about? AOL has blocked Jabber servers by IP in the past, they continue to do it today, and if they feel threatened by Jabber, they will do it even more in the future. Jabber.org no longer runs an AIM transport because they are blocked right now. This is one main reason people aren't moving to Jabber. Dynamic DNS doesn't solve the problem. For one thing, your service would be up and down like a yo-yo as it switched IPs. For another thing, it would still be trivial to detect and block Jabber servers: if a certain IP is trying to make more than, say, 10 connections to AIM, check to see if the Jabber port is open. If no, it must be a NAT box. This process is practically instant, so changing your IP wouldn't give you a week or even a day of time to use AIM, you would be blocked within a minute or two.
You laugh. See this picture? See those long piles that look like dirt? Those are piles of almond hulls and shells. See those tiny box-like things lined up next to them? Those are trailers for big rigs. A person would be less than a pixel high in this picture.
I imagine a plant for processing macadamia nuts would have a similar pile. There is a huge amount of waste in this process. Every nut you've ever eaten was covered by a shell and hull at least as massive as the part you consumed. In large piles such as these, the pressure and temperature in the middle start to rise. Bacteria decompose the organic matter and produce gases which (when combined with the rising temperature) can cause the piles to spontaneously catch on fire or even explode under certain conditions. So yeah, generating power from them isn't so far-fetched.
I know exactly what it's asking. I'm just annoyed that it's asking me. Normal people who don't use computers very often are scared by questions like that. I have no doubt that my sister would be able to figure out how to use Miranda. But it would take her a little while, and she wouldn't like it. It's little user interface touches like that that can make or break a program in the eyes of normal users. People who use computers every day don't understand: 1. how confusing and intimidating bad user interfaces are, and 2. how little effort people are willing to invest in learning a new program when their current one works.
You don't pay extra for email do you? Nobody would pay extra for Jabber, so ISPs couldn't charge extra for it if they wanted to. They can advertise that their service includes their own IM network though. There is no reason Windows users should like Jabber less than Linux users. In fact the best Jabber clients (IMHO) are Windows only.
The free version of trillian doesn't connect to Jabber (I don't know why on earth not). Rhymbox seems pretty neat though. Too bad it's not open source. It also doesn't have client-side connections to AIM/MSN/Yahoo/etc.
Did you read my reasons for not liking free Jabber clients? Miranda is too complex for my sister to use. She would hate it. When you first start the client, annoying questions and wizards should be kept to an *absolute* minimum. That means nothing beyond asking for existing accounts and passwords. In fact, it should automatically detect if you have AIM or whatever installed and pull your screen names out automatically. Miranda shouldn't be asking me "Choose how you would like to import: ( ) From a Miribalis ICQ (.99a or later) database", etc... It should look for any buddy lists it can find, use those, and not bother me about it. You shouldn't have to worry about the various protocols in use; they shouldn't even be exposed to the user beyond having a separate screen name and password for each. I'm sure Miranda is great for IM power users who have an account with every major service and manipulate their "away" or "busy" status separately for each service. But all that complexity is useless for me, for my sister, and thousands of IM users like us.
However, the blocking thing is a show-stopper. What good is an up-to-date AIM client bridge if your server is IP-banned from AIM? It is painfully obvious to AOL which connections are coming from Jabber servers, since one server might be signed on with 100-1000 different screen names, and they have specifically blocked servers in the past.
That's why the Jabber model is better. Instead of everyone in the world connecting to AOL's IM servers, you connect to your ISP's Jabber server. If you want to talk to someone, you use addresses like foobar42@aol.com or asdf@someISP.com, just like email. That way, you pay your ISP for the privilege of using their IM servers, the same as email. It's so completely obvious that this model is better that I wonder why Jabber hasn't taken over the world already.
Jabber is awesome. I don't understand why it isn't more widely used. Anyway, Jabber is somewhat decentralized because your IM is like an email address: somebody@somewhere.com. So Jabber user IDs specify the server as well as the username, meaning that Jabber can be a huge network of IM servers much like the email network. IMHO, when you sign up for an ISP, you should get youremail@yourISP.com as your email and a jabber account with the same ID. It's a perfect way for small ISPs to offer IM services to their users.
Maybe Jabber isn't widely used because the free clients suck. Please, somebody, make a *simple* Jabber client. By simple, I mean this: it asks you if you have an account. If no, it asks you what jabber ID you would like. If you put in an @server.com, it connects you to that server, otherwise it picks a nice default server for you (like jabber.org). Then you're done. No 10-page "account creation" wizards, no asking about port numbers and "jabber directory" information, no fooling with "resources". Just connect! The client should also be able to sign into other messaging services on the client side, because Jabber bridges require server support that may or may not be there, and AOL or MSN can easily block any one server from connecting on behalf of its users. The server is the wrong place to integrate with other IM systems, it should be done on the client.
Well, hey, while we've suddenly got control of the entire U.S. political machine, let's get rid of some other laws, too.
I'm speculating here. This is all pie-in-the-sky stuff, total thought experiment type stuff. There's no way in hell that Congress is going to change copyright like this anytime soon. But we can dream, can't we?;-)
I'm not saying you could pass some law saying "copyrights are non-transferable" and that would be it. You would definitely need to go through current laws and legal practice and change a bunch of things to make a coherent system out of this idea of non-transferable copyrights. What I'm saying is let's imagine we could do this; what would happen?
Hell, if we can pass a law saying that the corporation can't pre-own anything you do for them, the whole argument will dry up, because that's essentially the primary source of income for large corporations -- taking an innovation and automating/mass-producing it.
It does appear that in some cases "work for hire" makes sense. That's why I proposed elsewhere in the thread that people could still sign binding contracts giving eternal distribution rights to entities, as long as those contracts weren't *exclusive*. The artist/whatever who came up with the song/idea would still "own" it, and be able to do whatever he/she wanted with it. This would allow people to hire workers, and be able to use the products of their work, while the workers still have rights in their work as well.
Also, just because a certain specific business model in use today might not work so well under this new system doesn't mean the new system is automatically bad. We must weigh the different business models possible under the new system and the benefit to society as a whole as well.
Hmm. Maybe artists should be able to sign agreements giving perpetual distribution rights, as long as those rights aren't exclusive. The radio station and the bride/groom could get distribution rights, but the performer/photographer would still be able to do whatever he/she wanted with the jingle/photos.
Slashdot Mirror
As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the file system (ever tried setting creation dates on a file? ownership?).
What on earth do these two things have to do with Java's buffer overflow protection? If these things are hard to do in Java, that's because the APIs are badly designed, not because the language itself is secure. These are two totally different issues. It may be the case that Java's APIs are badly designed, but libraries can be replaced.
By which I mean, of course, "A SSH server written in Java will have zero buffer overflows that allow you to execute arbitrary code." I'm well aware that Java doesn't prevent DoS attacks. In fact, a Java server would probably be more prone to DoS attacks for several reasons. I consider this a reasonable price to pay for making it impossible to compromise the machine with arbitrary code, which can be much worse than a DoS.
All of the security holes in that paper are holes in the sandbox that Sun has constructed for running *untrusted* code such as applets. They have absolutely no relevance to trusted code, such as a server you are running on your machine. Yes, the JVM is written in C, but how many buffer overflows do you see in Sun's JVM? I've never even heard of one. Safely executing a well-defined series of bytecodes prepared in advance by a compiler whose job is to output correct instruction sequences is an easier problem than safely accepting arbitrary malicious input from a network connection.
Dude. Cyclone looks totally awesome. C, but with modern saftey features? And with ML-style datatypes and pattern matching? If they would just add type inference and a very simple object system, this language might just be the most perfect language ever. Are there any downsides?
It's very easy to understand. If you write your server in a language that prevents several common sources of root exploits, then the number of root exploits present in your code will be dramatically reduced. I would definitely be willing to put up with a server that was twice as slow if it had no possibility of buffer overflows, ever.
How about an $8.95 network card? You can probably get them for $6 or less in bulk. There's the cost savings.
That's why you get the kind of card that extends outside the computer and has a jack built in. Those dongles are worthless and anyone who buys one is just asking to buy a new network card in a year.
A super-breakthrough in battery technology that reduced both the size and weight of batteries by a factor of 10 might make this system reasonable. But at that point, your car could go 2000 miles on a single charge by putting 10 times the batteries in, which would take the same room and weigh the same as the batteries of today. At that point, it's better to just recharge the car overnight instead of worrying about swapping batteries.
Even better, it's already been integrated with KDE!
This is not a problem that should be solved by work for hire. If what you want is protection for people whose photos are taken, then you should think about how to provide that instead of using a totally different legal concept. What if someone you didn't hire takes an unflattering picture of you? You're just as screwed even with work for hire. Instead, the people whose pictures are taken should have joint ownership of the copyright with the photographer. If the photographer wants to distribute the photos then, he'll have to get a model release form saying that you approve of distribution by him.
There's no way a meta-template could ever out perform that because the level of hinting is so much higher in the the fortran 95 syntax
I disagree with that statement. Unfortunately, you didn't provide any evidence for me to dispute. Why do you believe that?
Did you even read the linked article? This statement beats optimized Fortran. Why? It uses a novel algorithm to traverse the 3D arrays that maximizes cache hits. To implement this in Fortran, you'd have to rewrite the compiler. In C++, this is simply a library feature. That's the difference. It's much easier to change a library than a compiler, so development of new features can happen much faster in a language that relies on libraries than in a language that puts major language features in the compiler itself. Faster development means more cool features to play with, and more time to optimize them. So much for your "language intrinsic will always beat a template" argument.
Discussion about the perfect copyright law can still be useful even if it doesn't directly apply to the US. There are plenty of other countries in the world, and in the future more will be created. If they have a better idea about the what the ideal copyright system would look like, they can model their systems after it instead of reusing the US model. And if the US is still around at that hypothetical time when other countries are using this new copyright model, then maybe it will be more receptive to changing its own model.
What are you talking about? AOL has blocked Jabber servers by IP in the past, they continue to do it today, and if they feel threatened by Jabber, they will do it even more in the future. Jabber.org no longer runs an AIM transport because they are blocked right now. This is one main reason people aren't moving to Jabber. Dynamic DNS doesn't solve the problem. For one thing, your service would be up and down like a yo-yo as it switched IPs. For another thing, it would still be trivial to detect and block Jabber servers: if a certain IP is trying to make more than, say, 10 connections to AIM, check to see if the Jabber port is open. If no, it must be a NAT box. This process is practically instant, so changing your IP wouldn't give you a week or even a day of time to use AIM, you would be blocked within a minute or two.
I imagine a plant for processing macadamia nuts would have a similar pile. There is a huge amount of waste in this process. Every nut you've ever eaten was covered by a shell and hull at least as massive as the part you consumed. In large piles such as these, the pressure and temperature in the middle start to rise. Bacteria decompose the organic matter and produce gases which (when combined with the rising temperature) can cause the piles to spontaneously catch on fire or even explode under certain conditions. So yeah, generating power from them isn't so far-fetched.
I know exactly what it's asking. I'm just annoyed that it's asking me. Normal people who don't use computers very often are scared by questions like that. I have no doubt that my sister would be able to figure out how to use Miranda. But it would take her a little while, and she wouldn't like it. It's little user interface touches like that that can make or break a program in the eyes of normal users. People who use computers every day don't understand: 1. how confusing and intimidating bad user interfaces are, and 2. how little effort people are willing to invest in learning a new program when their current one works.
You don't pay extra for email do you? Nobody would pay extra for Jabber, so ISPs couldn't charge extra for it if they wanted to. They can advertise that their service includes their own IM network though. There is no reason Windows users should like Jabber less than Linux users. In fact the best Jabber clients (IMHO) are Windows only.
The free version of trillian doesn't connect to Jabber (I don't know why on earth not). Rhymbox seems pretty neat though. Too bad it's not open source. It also doesn't have client-side connections to AIM/MSN/Yahoo/etc.
Did you read my reasons for not liking free Jabber clients? Miranda is too complex for my sister to use. She would hate it. When you first start the client, annoying questions and wizards should be kept to an *absolute* minimum. That means nothing beyond asking for existing accounts and passwords. In fact, it should automatically detect if you have AIM or whatever installed and pull your screen names out automatically. Miranda shouldn't be asking me "Choose how you would like to import: ( ) From a Miribalis ICQ (.99a or later) database", etc... It should look for any buddy lists it can find, use those, and not bother me about it. You shouldn't have to worry about the various protocols in use; they shouldn't even be exposed to the user beyond having a separate screen name and password for each. I'm sure Miranda is great for IM power users who have an account with every major service and manipulate their "away" or "busy" status separately for each service. But all that complexity is useless for me, for my sister, and thousands of IM users like us.
However, the blocking thing is a show-stopper. What good is an up-to-date AIM client bridge if your server is IP-banned from AIM? It is painfully obvious to AOL which connections are coming from Jabber servers, since one server might be signed on with 100-1000 different screen names, and they have specifically blocked servers in the past.
That's why the Jabber model is better. Instead of everyone in the world connecting to AOL's IM servers, you connect to your ISP's Jabber server. If you want to talk to someone, you use addresses like foobar42@aol.com or asdf@someISP.com, just like email. That way, you pay your ISP for the privilege of using their IM servers, the same as email. It's so completely obvious that this model is better that I wonder why Jabber hasn't taken over the world already.
Jabber is awesome. I don't understand why it isn't more widely used. Anyway, Jabber is somewhat decentralized because your IM is like an email address: somebody@somewhere.com. So Jabber user IDs specify the server as well as the username, meaning that Jabber can be a huge network of IM servers much like the email network. IMHO, when you sign up for an ISP, you should get youremail@yourISP.com as your email and a jabber account with the same ID. It's a perfect way for small ISPs to offer IM services to their users.
Maybe Jabber isn't widely used because the free clients suck. Please, somebody, make a *simple* Jabber client. By simple, I mean this: it asks you if you have an account. If no, it asks you what jabber ID you would like. If you put in an @server.com, it connects you to that server, otherwise it picks a nice default server for you (like jabber.org). Then you're done. No 10-page "account creation" wizards, no asking about port numbers and "jabber directory" information, no fooling with "resources". Just connect! The client should also be able to sign into other messaging services on the client side, because Jabber bridges require server support that may or may not be there, and AOL or MSN can easily block any one server from connecting on behalf of its users. The server is the wrong place to integrate with other IM systems, it should be done on the client.
I'm speculating here. This is all pie-in-the-sky stuff, total thought experiment type stuff. There's no way in hell that Congress is going to change copyright like this anytime soon. But we can dream, can't we? ;-)
I'm not saying you could pass some law saying "copyrights are non-transferable" and that would be it. You would definitely need to go through current laws and legal practice and change a bunch of things to make a coherent system out of this idea of non-transferable copyrights. What I'm saying is let's imagine we could do this; what would happen?
Hell, if we can pass a law saying that the corporation can't pre-own anything you do for them, the whole argument will dry up, because that's essentially the primary source of income for large corporations -- taking an innovation and automating/mass-producing it.
It does appear that in some cases "work for hire" makes sense. That's why I proposed elsewhere in the thread that people could still sign binding contracts giving eternal distribution rights to entities, as long as those contracts weren't *exclusive*. The artist/whatever who came up with the song/idea would still "own" it, and be able to do whatever he/she wanted with it. This would allow people to hire workers, and be able to use the products of their work, while the workers still have rights in their work as well.
Also, just because a certain specific business model in use today might not work so well under this new system doesn't mean the new system is automatically bad. We must weigh the different business models possible under the new system and the benefit to society as a whole as well.
Hmm. Maybe artists should be able to sign agreements giving perpetual distribution rights, as long as those rights aren't exclusive. The radio station and the bride/groom could get distribution rights, but the performer/photographer would still be able to do whatever he/she wanted with the jingle/photos.
Of course these kinds of agreements would be forbidden as well, if we wanted to pass this kind of law.