I'm not sure about the grandparent's post specifically, but many license schemes are purchased by license scheme makers, software houses who specialize in licensing. The node's identity is stored in a local file so that the license scheme can determine that licensing has properly occurred in the past and matches the current host. As a result, a licensed application can be allowed to work in configurable ways when the network connection to the license server is temporarily unavailable. For many software categories, building in downtime-buffers changes licensing from an absolutely unworkable problem to a manageable annoyance.
I unfortunately used to be the front man for a 100 million dollar a quarter software house, meaning I investigated and resolved all high profile issues on the topic, and worked with the developer who implemented the third party scheme to make it more reasonable for our customers. I would say between the two of us it used up a full technical employee salary, around 80k a year or so. Adding in all the people who dealt with FAQs about it, funnelled information to me, lost business, the cost of licensing the software, it easily cost the company over $500k a year. I always wished I could get good numbers on how much revenue it generated. I'm certain it was over $10k a quarter, but not sure how much.
The whole experience was one of the things that pushed me strongly in the direction of free software. Licensing is software functionality that is useful to no one. We hope that its indirect result is useful to us, but directly, it is waste of everyone's time.
The key to wiki adoption is all about critical mass. Encourage people to experiment on their own rather than telling them how to do it. Encourage them to use it for their own purposes. Keep up on RecentChanges and be sure to add useful things to stuff other people are working on.
I've had big successes at two companies, but you have to make it super easy to get into, and you have to be encouraging, and it does take time.
It doesn't really look maintained, but I really enjoyed Cygnus Source Navigator when I need to read a lot of source bases for a living. You can find it at http://sourcenav.sourceforge.net/ or probably as 'sourcenav' in the distribution of your choice.
The underlying technology is not the prettiest ever. Yeah it uses TCL. But it has a workmanlike efficacy in terms of interface. Give it a try.
For most smaller projects I just use vi and ctags, or maybe cscope with those, but I'm sure you're familiar with all that already.
AAC and MP3 are patent encumbered, but openly specified formats. FairPlay is not openly specified. There is a difference. This doesn't make what you said wrong, but it points out that you're being disingenuous.
As I'm sure google has told you by now, speex is an openly developed, hopefully patent-avoiding, streaming speech codec designed for network and file purposes (as opposed to channel). You can compare it with codecs currently used for cell phone telephony, apple audiobook, network telephony (vonage, skype), and so on.
On paper it appears to be the best quality per size codec. To the ear, however, skype seems to usually win. Speex is completely open however, which matters to some, such as me. After the project was already underway, it began to cooperate with the larger xiph/ogg group of codecs.
Yes blame the programmers. If only those programmers were magically better, then the tools would be JUST FINE. I'm sure when you stop hiding your magic hat from which you can produce an endless stream of perfect programmers that our long security crisis will be over.
Your argument can be easily extended without any real change to: You need to have a processor to execute compiled software, so therefore Freedom 0 is impossible.
Not everyone has a processor just as not everyone has the device that the driver intends to control. Just because the software works with some hardware does not prevent retransmission, reuse, modification, etc. Your claim that "a lot" of people believe that the need for free software has a special driver exception might be true, but the set of people who believe software freedom matters, but does not apply to drivers is an excruciatingly small fraction of the whole.
It's a weak analogy to start, in that network effects exist, but HIV is not a network effect and does not act like one. Once you see that it's a weak analogy it becomes a kind of nonsequitor dragging in HIV/AIDS, and smells like "Sony has aids!" as a kind of hamfisted tarring, or alternatively some kind of wierd backhand against people living with HIV.
I don't say that you meant those things, but that's what your words unintentionally suggest, which is why it is in poor taste.
What has happened that has enabled java to be used on "embedded" devices such as phones and PDAs is that they have stopped being low memory devices.
Typical embedded design memory space was in the 512k to 4 meg range when companies first started trying to deploy java into the space in 1997. I was there working with Wind River and transvirtual in that space. Java designs could barely manage to squeeze into 30 meg boards with the bare minimum of functionality.
Nowadays phones and "embedded" PDAs have 64 megabytes of memory and more, and have the most basic of computing functionality.
Traditionally "embedded" referred to devices which were not explicitly computers. Java is only performing strongly in devices which are becoming quite explicitly computers, and which have bountiful RAM for their tasks. There are some reasons why Java is a good fit for this space, but the memory footprint is not really the selling point.
I agree with your comments about perl. In its application domain, with its usual idioms, perl is extremely fast. Especially when you consider "the typical program", rather than some theoretical optimized case that rarely appears from real programmers.
Sadly Python, a language dear to my heart, has a lot more overhead in simply walking through the typing rules for objects macking stack frames, and the like. I feel all this overhead is very much worth it because the speed is often not important and it afford both safety and dynamicism. But it is a speed loser in nearly any benchmark. And Ruby is even slower (this is difficult for me to believe.)
Mind you, the incremental loss on these activities can completely come out in the wash in an application-sized body of code where python and ruby can lend themselves to simpler designs, but they will not win your proposed race.
Why are you arguing as if I stated that java uses more memory than C? Has downsides, sure, but the point is that Java is _the most memory hungry language in the entire world_.
You can go look at language shootouts showing example code and note how java always allocates the most memory. You can look at real world server applications (tomcat vs medus vs apache) or real world client applications (bittorrent vs rufus vs azureus). You will find that java is always using way more memory than the competition.
Java uses more memory than C. Java uses more memory than C++. Java uses more memory than Common Lisp. Java uses more memory than Smalltalk. Java uses more memory than Self. Java uses more memory than Erlang. Java uses more memory than Icon. Java uses more memory than Pascal. Java uses more memory than Simula. Java uses more memory than Python. Java uses more memory than BCPL. Java uses more memory than Perl. Java uses more memory than TCL. Java uses more memory than Haskell. Java uses more memory than Ocaml. Java uses more memory than javascript.
There is _no_ common denomonator to these languages. Some have virtual machines as sophisticated as the jvm. Some have simple hand-hacked runtimes. Some are compiled. Some have features and dynamicism Java cannot hope to touch. Some are terse. Some are verbose. Some are forgotten and old. Some are quite new. Java uses more memory than every single one, and that is a major weakness of java in practical terms at this time.
It may be funny but it's actually a legitimate approach. If you write a translator in language X that can get from language X to binary via some path, then you can write the compiler / vm for language X in language X. This has been accomplished in smalltalk with very impressive results. PyPy is coming along.
Java could do it too, should it be deemed useful and/or necessary.
In most cases it ends up being a rather pragmatic step, producing more efficient code/runtimes than the non-automated approach.
Let me get this straight. Sun Java is not fat. But wait! San Java 6 will be up to 55% thinner!
Meanwhile, top and ps may be _misleading_, but the resident size they report is not incorrect. Often the values you see are partially made up of libraries and allocations which are not the fault of the program, and VSize can be relatively meaningless for evaluating footprint, a couple of anonymous mmaps that you never use and your virtual size baloons.
All that said, the _resident_ memory allocated by the JVM is typically in the realm of hundreds of megs for applications which certainly do not require this. This is the kernel pages which are resident in real ram and not moved out. Java _does_ consume an exceedingly large amount of real RAM on linux systems currently, without using it as an efficiency boost.
I'm glad to hear that Sun is finally getting around to slimming down Java. That will eliminate the second major glaring problem with the platform.
I address question 1 elsewhere. There are legal barriers to convenient redistribution of the JVM.
Your second comment is a nonsequitor. My point is the Sun JVM is extremely greedy in allocating memory. You relate a story about a C/C++ project going poorly. Whether or not Java is a superior language and deployment environment for some types of applications (an argument I do not contest) is irrelevant to the fact that the Sun JVM significantly more memory than an equivalent program in a variety of other languages. There are many causes contributing to this, from the java gui classes, to common java programming style, to the Sun JVM memory fragmentation behavior and garbage collector. None of them is "fundamental". You could write better java code; you could clean up the gui classes or write better ones. The Sun JVM could be fixed or improved to have better behavior. On second thought I don't really know if the garbage collector semantics have any fundamental flaws, although I suspect they do not. In practice, however, all these problems do exist, and contribute to relatively plain longrunning java programs balooning to many tens of megabytes when other similar technologies (for example smalltalk) do not have any problems of the sort.
You may counter that java is nontheless a more practial virtual development environment than other available systems, a point I do not care to argue at this time. That is completely aside from the fact that the other comparable virtual execution evironments of comparable complexity do not suffer from nearly the same level of allocation bloat. Squeak for example executes a large virtual system complete with a wide variety of applications, runtime debugger and modifier, entire virtualized framebuffer, a comparably complex foundation library all within a few tens of megabytes, even when used over very long sessions. Java in similar situations will consume hundreds.
As for the second point, there _are_ other portable execution environments in the world, such as the python runtime, which do not have the same order of magnitude of memory fragmentation and very poor garbage collection that java tends to exhibit. Sun java has an amazing ability to lock hundreds of megabytes in core when very little is going on in the running application. It somehow manages to achieve nearly pathologically bad cases of memory use fragmentation and page faults to keep hundreds of megs allocated even under significant memory pressure.
Even when writing the most boneheaded python code with extremely naive object creation strategies that end up hitting the VM ceiling, I never manage to lock more than a few tens of megabytes in real RAM. There are some types of applications which will tend to exhibit this type of pattern unavoidably, but the Sun JVM seems to maximize the potential for this poor condition.
Many people point out that the cost goes down as you share the jvm across multiple applications. I have some reservations about the abandoning of memory space seperation between different servies, but practically speaking in many cases the intial hundred or hundred and fifty megs loss is simply too high to care about the much lower cost of the second java application. On a server where a box may be dedicated to a single task or set of tasks, throwing 2, 4, or more gigs at the problem may be totally reasonable. For ad-hoc tasks, desktop tasks, etc, it often a dealbreaker.
Great, now how do I install sun's java on LinuxPPC?
For another example, compare installing java on debian linux vs installing all open languages on debian linux. With everything but java it's a single command. This is _not_ because Debian is being all nitpicky as some would suggest, but because distributing it is against the terms of the license and thus illegal.
Yes, I'm aware there are java implementations that are reasonable, but in practice most java code encountered "in the wild" throws exceptions when it doesn't run on sun java, and sun java's memory behavior tends to swell to amazing size. This includes programs that have no gui.
To achieve energy equilibrium in an age of decreasing oil availability, without exploiting new sources, we will need to cut our energy consumption by around 95%.
I can see no way at all to achieve that, so as a result I wholeheartedly welcome exploration of alternative means of "thermal pollution", ie. energy production.
Fusion is not a panacea, agreed. There is generated radioactivity in the form of radioactive helium isotope emissions, and the induced readioactivity in the plant materials. There is the question of how you release the generated heat without damaging the local or global environment overmuch.
However, these problems are quite small as compared to what I expect will happen with coal use ramping up to cover dropping oil availability. And in human terms, they are also _very_ small to the probable results of a drastic non-optional drop in global energy availability.
If I were king of the world I would opt for the 95% energy use reduction, although implementing that might take decades. In the meantime, fusion (if workable) would be great.
But loudness is a measurement which is by its nature subjective to vagaries of human hearing and sound processing.
Of course I'm being slightly disingenuous, as what I said is true, but it does not generally mean perceived loudness as is comparative to prior quietness, etc. However, the THX sound is loud, and annoying. I wish they'd stop.
Slashdot Mirror
I'm not sure about the grandparent's post specifically, but many license schemes are purchased by license scheme makers, software houses who specialize in licensing. The node's identity is stored in a local file so that the license scheme can determine that licensing has properly occurred in the past and matches the current host. As a result, a licensed application can be allowed to work in configurable ways when the network connection to the license server is temporarily unavailable. For many software categories, building in downtime-buffers changes licensing from an absolutely unworkable problem to a manageable annoyance.
I unfortunately used to be the front man for a 100 million dollar a quarter software house, meaning I investigated and resolved all high profile issues on the topic, and worked with the developer who implemented the third party scheme to make it more reasonable for our customers. I would say between the two of us it used up a full technical employee salary, around 80k a year or so. Adding in all the people who dealt with FAQs about it, funnelled information to me, lost business, the cost of licensing the software, it easily cost the company over $500k a year. I always wished I could get good numbers on how much revenue it generated. I'm certain it was over $10k a quarter, but not sure how much.
The whole experience was one of the things that pushed me strongly in the direction of free software. Licensing is software functionality that is useful to no one. We hope that its indirect result is useful to us, but directly, it is waste of everyone's time.
Only the best sort of discussions are based on participants defining their terms differently from the norm, without clarifying at the outset.
The key to wiki adoption is all about critical mass. Encourage people to experiment on their own rather than telling them how to do it. Encourage them to use it for their own purposes. Keep up on RecentChanges and be sure to add useful things to stuff other people are working on.
I've had big successes at two companies, but you have to make it super easy to get into, and you have to be encouraging, and it does take time.
It doesn't really look maintained, but I really enjoyed Cygnus Source Navigator when I need to read a lot of source bases for a living. You can find it at http://sourcenav.sourceforge.net/ or probably as 'sourcenav' in the distribution of your choice.
The underlying technology is not the prettiest ever. Yeah it uses TCL. But it has a workmanlike efficacy in terms of interface. Give it a try.
For most smaller projects I just use vi and ctags, or maybe cscope with those, but I'm sure you're familiar with all that already.
Don't cloud the waters.
AAC and MP3 are patent encumbered, but openly specified formats. FairPlay is not openly specified. There is a difference. This doesn't make what you said wrong, but it points out that you're being disingenuous.
As I'm sure google has told you by now, speex is an openly developed, hopefully patent-avoiding, streaming speech codec designed for network and file purposes (as opposed to channel). You can compare it with codecs currently used for cell phone telephony, apple audiobook, network telephony (vonage, skype), and so on.
On paper it appears to be the best quality per size codec. To the ear, however, skype seems to usually win. Speex is completely open however, which matters to some, such as me. After the project was already underway, it began to cooperate with the larger xiph/ogg group of codecs.
More than that: A large percentage of the Cypress Structure replacement is on the ground.
It is hard to fall off the ground, so I hope that level of disaster does not occur again. The east span of the bay bridge however...
Yes blame the programmers. If only those programmers were magically better, then the tools would be JUST FINE. I'm sure when you stop hiding your magic hat from which you can produce an endless stream of perfect programmers that our long security crisis will be over.
Your argument can be easily extended without any real change to: You need to have a processor to execute compiled software, so therefore Freedom 0 is impossible.
Not everyone has a processor just as not everyone has the device that the driver intends to control. Just because the software works with some hardware does not prevent retransmission, reuse, modification, etc. Your claim that "a lot" of people believe that the need for free software has a special driver exception might be true, but the set of people who believe software freedom matters, but does not apply to drivers is an excruciatingly small fraction of the whole.
That's true. Knowing you, you wouldn't see it.
It's a weak analogy to start, in that network effects exist, but HIV is not a network effect and does not act like one. Once you see that it's a weak analogy it becomes a kind of nonsequitor dragging in HIV/AIDS, and smells like "Sony has aids!" as a kind of hamfisted tarring, or alternatively some kind of wierd backhand against people living with HIV.
I don't say that you meant those things, but that's what your words unintentionally suggest, which is why it is in poor taste.
Jimmy, this analogy is in poor taste.
What has happened that has enabled java to be used on "embedded" devices such as phones and PDAs is that they have stopped being low memory devices.
Typical embedded design memory space was in the 512k to 4 meg range when companies first started trying to deploy java into the space in 1997. I was there working with Wind River and transvirtual in that space. Java designs could barely manage to squeeze into 30 meg boards with the bare minimum of functionality.
Nowadays phones and "embedded" PDAs have 64 megabytes of memory and more, and have the most basic of computing functionality.
Traditionally "embedded" referred to devices which were not explicitly computers. Java is only performing strongly in devices which are becoming quite explicitly computers, and which have bountiful RAM for their tasks. There are some reasons why Java is a good fit for this space, but the memory footprint is not really the selling point.
Other languages trade memory for performance, and better. Python has immutable strings but doesn't bloat anywhere like java.
Yes it has some nice features but none of these featurse explain why the java runtime is so damn monstrously large. At least right now.
I agree with your comments about perl. In its application domain, with its usual idioms, perl is extremely fast. Especially when you consider "the typical program", rather than some theoretical optimized case that rarely appears from real programmers.
Sadly Python, a language dear to my heart, has a lot more overhead in simply walking through the typing rules for objects macking stack frames, and the like. I feel all this overhead is very much worth it because the speed is often not important and it afford both safety and dynamicism. But it is a speed loser in nearly any benchmark. And Ruby is even slower (this is difficult for me to believe.)
Mind you, the incremental loss on these activities can completely come out in the wash in an application-sized body of code where python and ruby can lend themselves to simpler designs, but they will not win your proposed race.
The opposite of verbose is not confusing. The opposite of verbose is concise.
Why are you arguing as if I stated that java uses more memory than C? Has downsides, sure, but the point is that Java is _the most memory hungry language in the entire world_.
You can go look at language shootouts showing example code and note how java always allocates the most memory. You can look at real world server applications (tomcat vs medus vs apache) or real world client applications (bittorrent vs rufus vs azureus). You will find that java is always using way more memory than the competition.
Java uses more memory than C.
Java uses more memory than C++.
Java uses more memory than Common Lisp.
Java uses more memory than Smalltalk.
Java uses more memory than Self.
Java uses more memory than Erlang.
Java uses more memory than Icon.
Java uses more memory than Pascal.
Java uses more memory than Simula.
Java uses more memory than Python.
Java uses more memory than BCPL.
Java uses more memory than Perl.
Java uses more memory than TCL.
Java uses more memory than Haskell.
Java uses more memory than Ocaml.
Java uses more memory than javascript.
There is _no_ common denomonator to these languages. Some have virtual machines as sophisticated as the jvm. Some have simple hand-hacked runtimes. Some are compiled. Some have features and dynamicism Java cannot hope to touch. Some are terse. Some are verbose. Some are forgotten and old. Some are quite new. Java uses more memory than every single one, and that is a major weakness of java in practical terms at this time.
It may be funny but it's actually a legitimate approach. If you write a translator in language X that can get from language X to binary via some path, then you can write the compiler / vm for language X in language X. This has been accomplished in smalltalk with very impressive results. PyPy is coming along.
Java could do it too, should it be deemed useful and/or necessary.
In most cases it ends up being a rather pragmatic step, producing more efficient code/runtimes than the non-automated approach.
Let me get this straight. Sun Java is not fat. But wait! San Java 6 will be up to 55% thinner!
Meanwhile, top and ps may be _misleading_, but the resident size they report is not incorrect. Often the values you see are partially made up of libraries and allocations which are not the fault of the program, and VSize can be relatively meaningless for evaluating footprint, a couple of anonymous mmaps that you never use and your virtual size baloons.
All that said, the _resident_ memory allocated by the JVM is typically in the realm of hundreds of megs for applications which certainly do not require this. This is the kernel pages which are resident in real ram and not moved out. Java _does_ consume an exceedingly large amount of real RAM on linux systems currently, without using it as an efficiency boost.
I'm glad to hear that Sun is finally getting around to slimming down Java. That will eliminate the second major glaring problem with the platform.
I address question 1 elsewhere. There are legal barriers to convenient redistribution of the JVM.
Your second comment is a nonsequitor. My point is the Sun JVM is extremely greedy in allocating memory. You relate a story about a C/C++ project going poorly. Whether or not Java is a superior language and deployment environment for some types of applications (an argument I do not contest) is irrelevant to the fact that the Sun JVM significantly more memory than an equivalent program in a variety of other languages. There are many causes contributing to this, from the java gui classes, to common java programming style, to the Sun JVM memory fragmentation behavior and garbage collector. None of them is "fundamental". You could write better java code; you could clean up the gui classes or write better ones. The Sun JVM could be fixed or improved to have better behavior. On second thought I don't really know if the garbage collector semantics have any fundamental flaws, although I suspect they do not. In practice, however, all these problems do exist, and contribute to relatively plain longrunning java programs balooning to many tens of megabytes when other similar technologies (for example smalltalk) do not have any problems of the sort.
You may counter that java is nontheless a more practial virtual development environment than other available systems, a point I do not care to argue at this time. That is completely aside from the fact that the other comparable virtual execution evironments of comparable complexity do not suffer from nearly the same level of allocation bloat. Squeak for example executes a large virtual system complete with a wide variety of applications, runtime debugger and modifier, entire virtualized framebuffer, a comparably complex foundation library all within a few tens of megabytes, even when used over very long sessions. Java in similar situations will consume hundreds.
As for the second point, there _are_ other portable execution environments in the world, such as the python runtime, which do not have the same order of magnitude of memory fragmentation and very poor garbage collection that java tends to exhibit. Sun java has an amazing ability to lock hundreds of megabytes in core when very little is going on in the running application. It somehow manages to achieve nearly pathologically bad cases of memory use fragmentation and page faults to keep hundreds of megs allocated even under significant memory pressure.
Even when writing the most boneheaded python code with extremely naive object creation strategies that end up hitting the VM ceiling, I never manage to lock more than a few tens of megabytes in real RAM. There are some types of applications which will tend to exhibit this type of pattern unavoidably, but the Sun JVM seems to maximize the potential for this poor condition.
Many people point out that the cost goes down as you share the jvm across multiple applications. I have some reservations about the abandoning of memory space seperation between different servies, but practically speaking in many cases the intial hundred or hundred and fifty megs loss is simply too high to care about the much lower cost of the second java application. On a server where a box may be dedicated to a single task or set of tasks, throwing 2, 4, or more gigs at the problem may be totally reasonable. For ad-hoc tasks, desktop tasks, etc, it often a dealbreaker.
Great, now how do I install sun's java on LinuxPPC?
For another example, compare installing java on debian linux vs installing all open languages on debian linux. With everything but java it's a single command. This is _not_ because Debian is being all nitpicky as some would suggest, but because distributing it is against the terms of the license and thus illegal.
Yes, I'm aware there are java implementations that are reasonable, but in practice most java code encountered "in the wild" throws exceptions when it doesn't run on sun java, and sun java's memory behavior tends to swell to amazing size. This includes programs that have no gui.
There are two major reasons I do not run java programs if I can help it in any capacity.
1. Restrictive licenses make it more difficult to reasonably deploy than any competing technology in a linux environment.
2. JVM is fat fat fat, it uses way more RAM than is reasonable.
Other than these two issues, it would be reasonable to run java software on linux, even if I don't love the language, environment in some ways.
To achieve energy equilibrium in an age of decreasing oil availability, without exploiting new sources, we will need to cut our energy consumption by around 95%.
I can see no way at all to achieve that, so as a result I wholeheartedly welcome exploration of alternative means of "thermal pollution", ie. energy production.
Fusion is not a panacea, agreed. There is generated radioactivity in the form of radioactive helium isotope emissions, and the induced readioactivity in the plant materials. There is the question of how you release the generated heat without damaging the local or global environment overmuch.
However, these problems are quite small as compared to what I expect will happen with coal use ramping up to cover dropping oil availability. And in human terms, they are also _very_ small to the probable results of a drastic non-optional drop in global energy availability.
If I were king of the world I would opt for the 95% energy use reduction, although implementing that might take decades. In the meantime, fusion (if workable) would be great.
But loudness is a measurement which is by its nature subjective to vagaries of human hearing and sound processing.
Of course I'm being slightly disingenuous, as what I said is true, but it does not generally mean perceived loudness as is comparative to prior quietness, etc. However, the THX sound is loud, and annoying. I wish they'd stop.