I think that even if you knew the formula for Coke, it wouldn't matter, because Coke's brand is more important.
Think about it, if you had the formula, it's not like you could make and sell Coke, you'd have to make and sell a Cola drink that 'tastes exactly like Coke'. Since Coke still owns the trademark of Coke. And I don't think that in people's mind's your cola would taste exactly the same if they thought that they were not drinking Coke. Just because it's not Coke, people would think 'this doesn't taste the same'.
Believe it or not, there are homeless people in the US and it does seem a little silly to me to pay people to kill other nations while there are people in our own country that don't even get a meal every day.
I never said that the US should feed the world, the US should do a better job of ensuring it's own people's welfare before going out and conquring more lands. But that's just my opinion, and apparently not a popular one.
Why do you say that it costs the ISPs no money to have people with viruses on their networks? It costs them money to have bits flowing on their wires, as opposed to not having any bits. I guess if you think that bits are completly free then it makes no difference to them but I'm fairly sure that the cost of everyone using their connection is NOT free to the ISP.
Also, IMO, selling security services is a bad idea because then the ISP can be held liable when the users DO get viruses, and they will. No amount of filtering will prevent that. However, if they just shut down all incoming connections and don't guarentee that the users will be safe they are out of the loop. Basically, when you're in an untrusted network, (like the internet) paranoia is a way of life. You can't trust anything about a packet that arrives from your incoming interface. And you should always double check your outbound data to make sure it's sane as well.
ISPs usually pay for how much bandwidth they use, so saving on bits transferred is good for them.
But that's ignoring the costs of what happens because you don't filter.
The MSBlaster worm shows that the costs of filtering are sometimes lower then the costs of not filtering. The costs of dealing with the Worm are high, it could to have been slowed if ISPs just blocked all inbound connections to normal home users who have no clue. Which is most people. The few people who want to be able to accept inbound connections and run services can pay for the priviledge.
I know that it's not that simple, and that it's not proven that the costs of filtering are lower then not filtering. In fact, filtering all connections is not only a PITA for ISPs, but goes against the spirit of the internet.
I do think that the unwashed masses whould rather have a limited connection that works 99% of the time rather then a full connection that breaks their computer. ( and costs them lots of time and $$ to fix )
I disagree, that filtered should be more, rather unfiltered should cost money. Let's face it, the people who want to use the internet as it was designed are in the minority. Most people see it as a service like cable TV. So either you redesign the internet to be like cable TV, or you filter it so that it's safe.
The internet is cheap because the unwashed masses are useing it. How much money was it to get even a 128k ISDN line to the internet ten years ago? A hell of a lot more then a DSL line is today.
The internet needs the masses to be a success and I think that it's the duty of the ISPs to ensure that those people don't kill each other with viruses.
BTW, MS will never be shamed into making secure software, because people don't blame MS for the viruses. Nor should they be. MS is the number one target because it is number one. If Linux, Mac, BSD, Sun, etc. was number one then they would be the number one target.
Listen, 64-bit is not a hardware issue as much as it is a software issue. Yes, the hardware support needs to be there first, but really it about wether or not the software will actually use the 64-bit modes.
It's not like 64-bit is always a win-win situation. Some programs will always run faster when compiled in a 32-bit addressing mode simply because 32-bit can be more efficient when not addressing large amounts of ram. Just like there are programs that can be written entirely withing the 16-bit addressing modes of the x86 that will outperform the 32-bit version. Though I would guess that today that number is rather small.
I hope that the Mac continues to be a hybrid of 32 and 64 bit programs for awhile. It won't be expensive to maintain compatability from the OS perspective, and it will ensure that all of us that don't want to upgrade will be able to run all the software for awhile.
Apple already has the infistructure in place so that people with G5s will be able to run G5 versions and people with G4s will be able to run a G4 version. Their executable format allows for multiple versions of the same program so that the developers can simple recompile for the G5 ahead of time and package it with the G4 version in the same file. (like the old 'fat' binaries of yore with 68k and ppc code in them)
Besides, you can't 'just recompile' and get benefits of 64 computing. It's not that simple. If you don't program with the intent of being x-platform then you can't recompile and have it work. Also, as you hinted, the G5 has a radically different idea about what kind of code it optimal compared to the G4, thus any code targeted for the G4 will perform sub-standard. We'll just have to wait a month or two until all the software catches up to the hardware. The G5 will only seem to get faster and faster as more software is retargeted for it.
The G5 is more then a step up in clock speed, it's a whole new generation of processor, a bigger step from the G3 to G4. But no matter how you look at it, it's a step up. Maybe not as big as you want it to be and this is something that I think a few people are (still) sore about.
Ok, this thread is very far from my original responces intent, but I would like to say that yes you're right about the perl source being executable, because yes, it is. You could build into the kernal a Perl interpreter and then there would be no difference between a perl.pl and a normal executable. Though you'd probably want a special header on the.pl file (magic number and whatnot) to identify it correctly. Rather then rely on the file extension.
Also, it really doesn't matter how Sun's chip executed the Java bytecode internally. It ran java bytecode, you put in bytecode, you get out the proper result. All modern x86 CPUs do dynamic recompiliation of the code to a simple RISC style instruction set. And before that they used microcode, which translated the x86 operations (using software) into the actual internal instructions that the cpu used.
Java bytecode is an executable. It's executable by a Java Machine. There's only a few java machines out the, Sun created a chip that could run bytecode native and ARM has extensions that run most bytecode directly on the chip.
You don't compile code to increase performance. Like the parent post said, you compile code so that the machine can understand it. Period.
Also, the reason that Java can be easily decompiled is because the output of the Java compiler doesn't obfuscate the code at all. Basically the output of the compiler is VERY deterministic and the transformation can be reversed. Since the java compiler has almost no optimization options, it bascially does a one-to-one translation to your source code to Java ByteCode, and not much is lost in the process. (If you compile with debugging information, the only thing lost is comments. Line numbers, local variables,etc are all preserved).
C Compilers (which most people use) on the other hand, there are many different brands from different vendors, all of which output different code and all have multiple different levels of optimization. Also, don't forget that a binary may not actually be from a C source. It could be Fortran, C++, Java (yes there is a Java->x86 compiler), etc. Thus decompiling a random binary may be very hard if you don't know what it was written in.
So you're saying that reading a executabe for any other reason then plain execution is illegal? That's crazy.
That's my point, that when you buy a CD, you are buying 2 things, a physical CD, and a license to actually play the content on that CD. That license is however restricted by US copyright law. AKA, you can't do whatever you want with the CD.
If you buy a CD containing uncopyrighted (public domain for example) music, then you are free to do whatever you want with the contents of the CD.
I fail to see how you do not have a license to the music when you buy it. (otherwise why not just copy a friend's CD).
EULAs impose additional restrictions upon the software that you buy. There is already the restriction of copyright upon the software but eulas impose further blocks upon the software.
So you're saying that once you get your hands on the CD you can do whatever you want with the music on the CD? Copy, resell it, publicly perform using that music?
Sorry, but there is a license that you have to abide by, it's covered under copyright law.
I think though that the license could be interepreted such that the content of the CD can only be played one at a time. So that if you make a copy of the CD, you can then only play either the original or the copy, but not simultaneously. Like many people I have almost all my songs from CD copied to MP3, and have multiple copies of the mp3's, on backup cd's, at work and on my home computer. But only one version of any song is being played at one time so I'm fairly sure that I'm still in fair use.
For most programmers, we are just looking for a way to embed a small HTML rendering system so that we can display documentation, help, or someother hyperlinked document. Quickly too, so that we can easily get back to making a quality application. Gecko is a huge project and if you want to use it as the basis for an application more power to ya.
However, Apple has the edge here with WebCore, you can now make a generic web browser without a single line of C/C++/ObjC code. Using only project builder, Interface Builder and WebCore, you can create a custom browser. It won't have many options, but it's quick and easy. Takes like 10 minutes to get working if you have all the tools installed.
The design is really to minimize noise I think because if you have lots of slow moving fans, it's a lot quieter then one or two fast moving ones.
Computers put out too much heat to use passive cooling anymore, the old computers of yore didn't use fans, but people today don't want slow machines so we have to use active cooling.
I guess my point was more that without the Military, NASA wouldn't exist today because it whole purpose for it was to combat 'those nasty russians' in a PR war at the time. If it wasn't for the PR factor, the Airforce (or some military force) would to have figured out how to launch spaceships and put satilites in space as it was obvious that being able to put spy satilites in space was a big deal. Making NASA a civilian agency also means that you don't have to make all your workers get secret clearance to work on a project like that. Since it was public knowledge taht we were going to space.
You do realize that the entire reason the usa had such a large space program was a PR thing. That we were afraid of being 'second best' in the space race. It's not buracracy, but just the american public that doesn't want to goto space.
We still have the same shuttles because they are probably cheaper then building new ones. NASA was spawned from the Airforce and still is relient on military money for many projects.
Singular millionaries will goto space, because they want to, while most people are fine here on earth.
I would say that this will only apply to applications that are popular. Given that most programs are not in fact popular. That only a small handfull of programs are used by many people and thus only a small handfull will get used by enough people to get the advantages of open source to work. The whole 'many eyeballs' theory falls flat when only you and like 5 other people in the whole world are interisted in your project. If you're writing a program to simulate the life of a slug, only a small handfull of people are going to want to use it, and only a much smaller number will be able to actually help you improve it.
For programs that only a few people want, OSS sucks. That's why the software for artists that is OSS is no where near as good as the commercial applications.
Why are the so many IDE projects? So many server programs? Why are there few 3-d modelers?
No, it's messed up. Repeated images where there shouldn't be, strangely scaled images and it doesn't fix itself after a refresh of the screen. Very strange.
However, not all aspects of thread scheduling, printing, graphics display, event handling order are actually defined in the JVM or any cross platform VM. In fact many of these details are left to the VM writer so that they can implement a more efficient VM rather then one that meets some arbitrary definition of thread scheduling.
Maybe, maybe not. Depends on what you are writing. Java is really fast to develop in compared to C++ and if you already know Java it's even faster to develop in.
It's nice when you don't have to learn like 5 skillsets just to write a program.
Regardless of the VM it's run on. Many java programs are never going to be run on any other platforms. Write-once is such a lie anyway, Java programs rarely work flawlessly on every platform. Any non-trivial application will have som issue with the platform it's run on. It might be file access, thread scheduling, nulls returned where there are no nulls, or missing classes. ( Apple's vm doesn't support javax.print classes, but most everything else ) All java code must be tested in every envoriment you expect it to run in, else you can't be sure that it will work at all.
Slashdot Mirror
I think that even if you knew the formula for Coke, it wouldn't matter, because Coke's brand is more important.
Think about it, if you had the formula, it's not like you could make and sell Coke, you'd have to make and sell a Cola drink that 'tastes exactly like Coke'. Since Coke still owns the trademark of Coke. And I don't think that in people's mind's your cola would taste exactly the same if they thought that they were not drinking Coke. Just because it's not Coke, people would think 'this doesn't taste the same'.
Believe it or not, there are homeless people in the US and it does seem a little silly to me to pay people to kill other nations while there are people in our own country that don't even get a meal every day.
I never said that the US should feed the world, the US should do a better job of ensuring it's own people's welfare before going out and conquring more lands. But that's just my opinion, and apparently not a popular one.
Why do you say that it costs the ISPs no money to have people with viruses on their networks? It costs them money to have bits flowing on their wires, as opposed to not having any bits. I guess if you think that bits are completly free then it makes no difference to them but I'm fairly sure that the cost of everyone using their connection is NOT free to the ISP.
Also, IMO, selling security services is a bad idea because then the ISP can be held liable when the users DO get viruses, and they will. No amount of filtering will prevent that. However, if they just shut down all incoming connections and don't guarentee that the users will be safe they are out of the loop. Basically, when you're in an untrusted network, (like the internet) paranoia is a way of life. You can't trust anything about a packet that arrives from your incoming interface. And you should always double check your outbound data to make sure it's sane as well.
ISPs usually pay for how much bandwidth they use, so saving on bits transferred is good for them.
Wrong, they would only fund it if you could make a robot killing machine. Duh, the spends more on weapons then on food, always has, always will.
But that's ignoring the costs of what happens because you don't filter.
The MSBlaster worm shows that the costs of filtering are sometimes lower then the costs of not filtering. The costs of dealing with the Worm are high, it could to have been slowed if ISPs just blocked all inbound connections to normal home users who have no clue. Which is most people. The few people who want to be able to accept inbound connections and run services can pay for the priviledge.
I know that it's not that simple, and that it's not proven that the costs of filtering are lower then not filtering. In fact, filtering all connections is not only a PITA for ISPs, but goes against the spirit of the internet.
I do think that the unwashed masses whould rather have a limited connection that works 99% of the time rather then a full connection that breaks their computer. ( and costs them lots of time and $$ to fix )
I disagree, that filtered should be more, rather unfiltered should cost money. Let's face it, the people who want to use the internet as it was designed are in the minority. Most people see it as a service like cable TV. So either you redesign the internet to be like cable TV, or you filter it so that it's safe.
The internet is cheap because the unwashed masses are useing it. How much money was it to get even a 128k ISDN line to the internet ten years ago? A hell of a lot more then a DSL line is today.
The internet needs the masses to be a success and I think that it's the duty of the ISPs to ensure that those people don't kill each other with viruses.
BTW, MS will never be shamed into making secure software, because people don't blame MS for the viruses. Nor should they be. MS is the number one target because it is number one. If Linux, Mac, BSD, Sun, etc. was number one then they would be the number one target.
They're not lying at all though.
Listen, 64-bit is not a hardware issue as much as it is a software issue. Yes, the hardware support needs to be there first, but really it about wether or not the software will actually use the 64-bit modes.
It's not like 64-bit is always a win-win situation. Some programs will always run faster when compiled in a 32-bit addressing mode simply because 32-bit can be more efficient when not addressing large amounts of ram. Just like there are programs that can be written entirely withing the 16-bit addressing modes of the x86 that will outperform the 32-bit version. Though I would guess that today that number is rather small.
I hope that the Mac continues to be a hybrid of 32 and 64 bit programs for awhile. It won't be expensive to maintain compatability from the OS perspective, and it will ensure that all of us that don't want to upgrade will be able to run all the software for awhile.
Apple already has the infistructure in place so that people with G5s will be able to run G5 versions and people with G4s will be able to run a G4 version. Their executable format allows for multiple versions of the same program so that the developers can simple recompile for the G5 ahead of time and package it with the G4 version in the same file. (like the old 'fat' binaries of yore with 68k and ppc code in them)
Besides, you can't 'just recompile' and get benefits of 64 computing. It's not that simple. If you don't program with the intent of being x-platform then you can't recompile and have it work. Also, as you hinted, the G5 has a radically different idea about what kind of code it optimal compared to the G4, thus any code targeted for the G4 will perform sub-standard. We'll just have to wait a month or two until all the software catches up to the hardware. The G5 will only seem to get faster and faster as more software is retargeted for it.
The G5 is more then a step up in clock speed, it's a whole new generation of processor, a bigger step from the G3 to G4. But no matter how you look at it, it's a step up. Maybe not as big as you want it to be and this is something that I think a few people are (still) sore about.
Ok, this thread is very far from my original responces intent, but I would like to say that yes you're right about the perl source being executable, because yes, it is. You could build into the kernal a Perl interpreter and then there would be no difference between a perl .pl and a normal executable. Though you'd probably want a special header on the .pl file (magic number and whatnot) to identify it correctly. Rather then rely on the file extension.
Also, it really doesn't matter how Sun's chip executed the Java bytecode internally. It ran java bytecode, you put in bytecode, you get out the proper result. All modern x86 CPUs do dynamic recompiliation of the code to a simple RISC style instruction set. And before that they used microcode, which translated the x86 operations (using software) into the actual internal instructions that the cpu used.
Java bytecode is an executable. It's executable by a Java Machine. There's only a few java machines out the, Sun created a chip that could run bytecode native and ARM has extensions that run most bytecode directly on the chip.
You don't compile code to increase performance. Like the parent post said, you compile code so that the machine can understand it. Period.
Also, the reason that Java can be easily decompiled is because the output of the Java compiler doesn't obfuscate the code at all. Basically the output of the compiler is VERY deterministic and the transformation can be reversed. Since the java compiler has almost no optimization options, it bascially does a one-to-one translation to your source code to Java ByteCode, and not much is lost in the process. (If you compile with debugging information, the only thing lost is comments. Line numbers, local variables,etc are all preserved).
C Compilers (which most people use) on the other hand, there are many different brands from different vendors, all of which output different code and all have multiple different levels of optimization. Also, don't forget that a binary may not actually be from a C source. It could be Fortran, C++, Java (yes there is a Java->x86 compiler), etc. Thus decompiling a random binary may be very hard if you don't know what it was written in.
So you're saying that reading a executabe for any other reason then plain execution is illegal? That's crazy.
That's my point, that when you buy a CD, you are buying 2 things, a physical CD, and a license to actually play the content on that CD. That license is however restricted by US copyright law. AKA, you can't do whatever you want with the CD.
If you buy a CD containing uncopyrighted (public domain for example) music, then you are free to do whatever you want with the contents of the CD.
I fail to see how you do not have a license to the music when you buy it. (otherwise why not just copy a friend's CD).
EULAs impose additional restrictions upon the software that you buy. There is already the restriction of copyright upon the software but eulas impose further blocks upon the software.
So you're saying that once you get your hands on the CD you can do whatever you want with the music on the CD? Copy, resell it, publicly perform using that music?
Sorry, but there is a license that you have to abide by, it's covered under copyright law.
I think though that the license could be interepreted such that the content of the CD can only be played one at a time. So that if you make a copy of the CD, you can then only play either the original or the copy, but not simultaneously.
Like many people I have almost all my songs from CD copied to MP3, and have multiple copies of the mp3's, on backup cd's, at work and on my home computer. But only one version of any song is being played at one time so I'm fairly sure that I'm still in fair use.
Or just simply don't file swap. It's really that easy.
If you want to avoid the whole mess, just don't bother swapping files with anyone you don't know.
For most programmers, we are just looking for a way to embed a small HTML rendering system so that we can display documentation, help, or someother hyperlinked document. Quickly too, so that we can easily get back to making a quality application. Gecko is a huge project and if you want to use it as the basis for an application more power to ya.
However, Apple has the edge here with WebCore, you can now make a generic web browser without a single line of C/C++/ObjC code. Using only project builder, Interface Builder and WebCore, you can create a custom browser. It won't have many options, but it's quick and easy. Takes like 10 minutes to get working if you have all the tools installed.
The design is really to minimize noise I think because if you have lots of slow moving fans, it's a lot quieter then one or two fast moving ones.
Computers put out too much heat to use passive cooling anymore, the old computers of yore didn't use fans, but people today don't want slow machines so we have to use active cooling.
I guess my point was more that without the Military, NASA wouldn't exist today because it whole purpose for it was to combat 'those nasty russians' in a PR war at the time. If it wasn't for the PR factor, the Airforce (or some military force) would to have figured out how to launch spaceships and put satilites in space as it was obvious that being able to put spy satilites in space was a big deal. Making NASA a civilian agency also means that you don't have to make all your workers get secret clearance to work on a project like that. Since it was public knowledge taht we were going to space.
You do realize that the entire reason the usa had such a large space program was a PR thing. That we were afraid of being 'second best' in the space race. It's not buracracy, but just the american public that doesn't want to goto space.
We still have the same shuttles because they are probably cheaper then building new ones. NASA was spawned from the Airforce and still is relient on military money for many projects.
Singular millionaries will goto space, because they want to, while most people are fine here on earth.
I would say that this will only apply to applications that are popular. Given that most programs are not in fact popular. That only a small handfull of programs are used by many people and thus only a small handfull will get used by enough people to get the advantages of open source to work. The whole 'many eyeballs' theory falls flat when only you and like 5 other people in the whole world are interisted in your project. If you're writing a program to simulate the life of a slug, only a small handfull of people are going to want to use it, and only a much smaller number will be able to actually help you improve it.
For programs that only a few people want, OSS sucks. That's why the software for artists that is OSS is no where near as good as the commercial applications.
Why are the so many IDE projects? So many server programs? Why are there few 3-d modelers?
No, it's messed up. Repeated images where there shouldn't be, strangely scaled images and it doesn't fix itself after a refresh of the screen. Very strange.
Is it just me or does anyone else have problems rendering Penny-arcade.com with the new 1.4 mozilla on windows?
However, not all aspects of thread scheduling, printing, graphics display, event handling order are actually defined in the JVM or any cross platform VM. In fact many of these details are left to the VM writer so that they can implement a more efficient VM rather then one that meets some arbitrary definition of thread scheduling.
Maybe, maybe not. Depends on what you are writing. Java is really fast to develop in compared to C++ and if you already know Java it's even faster to develop in.
It's nice when you don't have to learn like 5 skillsets just to write a program.
Regardless of the VM it's run on. Many java programs are never going to be run on any other platforms. Write-once is such a lie anyway, Java programs rarely work flawlessly on every platform. Any non-trivial application will have som issue with the platform it's run on. It might be file access, thread scheduling, nulls returned where there are no nulls, or missing classes. ( Apple's vm doesn't support javax.print classes, but most everything else ) All java code must be tested in every envoriment you expect it to run in, else you can't be sure that it will work at all.