Yes, the file will be just as big; however, the contents of the file will be compressible on their own, and they'll also be correlated to the contents of the lossy layers (since a wavelet will only appear in the lossless layer if a wavelet generated by the lossy layers blocked it out).
With all that said, though, I'm not confident that it's worth the time. An audio server serving a HUGE number of clients with unpredictable needs might possibly benefit from the CPU savings inherent to this, but such a server would not be legally possible right now anyhow; by the time it's possible, it's almost certain that P2P technology similar to BitTorrent will be more useful.
And my home collection won't benefit; I'd rather use the most space-efficient means, not something to save CPU power for my rare format conversions. So FLAC wins (well, right now, for me MP3 wins).
FLAC couldn't be adapted to this, because it's intrinsically lossless; converting it to lossy would require a full conversion, might as well just re-encode it as Ogg.
HOWEVER, it's possible that Ogg could be adapted the other way, adding another layer to it to make it lossless (probably by computing the difference between the lossy result and the actual source, and compressing the resulting stream). The result would be larger and MUCH more computation-demanding to play than FLAC, but it would be lossless and peelable.
I don't have any idea how much larger or more computation-dependant it would be.
A buddy of mine stuck a hunting arrow thru a potato (needed the spud to get an airtight seal) and fired it from his spud gun. The arrow went right thru the sheet of plywood he was aiming at...
Don't waste an arrow -- a properly built potato cannon will put the tuber through 3/4 inch plywood.
I like the idea of writing the tests as you go along, but some of the "small" steps I've seen in examples are stupid. For example, writing the test but not completely filling in the frame work for the code of the object being tested.
Yes, that's an example of an example trying to make a point: it's very easy to run the tests, so you'll often run the tests before the code's ready to compile. In real life, this happens a lot, no matter how silly it looks in a book: it's way more expensive to put in too much functionality than it is to put in too little, since if you put in too much your tests won't complain.
BUT, you don't have to do that. The #2 rule in the Pragmatic Programmers book is "THINK!" Good advice -- don't turn your brain off.
In some ways this is just a rehash of the methodolgy of structured programming. The way I was taught to break thigns down was to write the higher level code first, and this meant writing empty functions (or functions that return a constant). After that was done, you'd go back and fill in the code in increments. This just seems to be a rehash of that idea--which seemed to get lost mess when the OO craze started.
I see what you mean, but although this provides some wonderful support for top-down programming, it's not what it is or requires. It's just as easy to start in the middle and design outwards.
"his book Refactoring... describes his experience as a consultant refactoring medium sized software projects, and gives a lot of advice on methods for refactoring.
That's not even close to an accurate description. Refactoring describes what R. is, why it's done, what you need in order to do it, and how to do some common types.
At that point [Fowler] joined forces with Beck and formed his second reason for being well known, XP.
Even more wrong. XP was developed from the conventions and experience of a lot of Smalltalk developers over quite some time. Fowler and Beck didn't invent or develop it; they came in after it was initially publicised.
As far as I can tell, the philosophy of XP is, "Software usually ends up sucking and in need of refactoring after it has been extended too far. Why wait for it to be extended too far? Just make it suck in the first place and refactor all the time!"
That's an interesting caricature, actually. There's more truth in it than in anything else you've said. XP does say that software usually ends up sucking because it's been extended too far without refactoring; so why wait for it to be extended too far? Refactor so it won't suck NOW.
The conclusion you imply (that after the refactoring the code will suck worse) is blatantly wrong, of course -- but that's just a troll.
Perhaps a better way of looking at XP is to observe that it tries to pull the software into maintenance mode as soon as possible, and make change as cheap as possible within maintenance mode.
So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.
The name of the practice is either Test Driven Development or (more commonly) Test Driven Design. I think it's a bad name, because it leads to the sort of confusion you have.
The tests they're talking about ARE design, so by writing them before you write code, you are, in fact, designing before coding. The difference is twofold: first, instead of stopping the design at an arbitrary level of detail and going to some other part of the program, you continue the detailed design until it produces code for that part of the program; second, instead of writing your design in an ignorable form, you write it in a simple, immediately testable form.
Because of the first difference, you get to implement your design while it's still fresh in your head; because of the second, your implementation will be forced to match your design.
I've worked with TDD for about a year now. It's a real winner -- mainly because it makes testing a creative, constructive activity (part of design) instead of destructive gruntwork (intended to tear down parts of your program).
Waiting until you've cobbled something together that passes the test... is a loser.
Waiting? That's exactly the point -- you DON'T wait. You implement the solution needed to pass the test (i.e. the design) immediately, as soon as you've managed to express your design in a testable form. You get to see immediately whether or not your design is workable, before you build some other aspect of your design on it....hoping that your boss will allow you to refactor is a loser.
I've worked TDD both with and without refactoring. It works either way -- without refactoring I have to take a few more risks, code a little slower, and accept slightly lower quality overall code (i.e. it doesn't fit together quite as well; refactoring doesn't slow me down at all. The nice thing is, though, that it's not under the control of my boss, anymore than which shift key I use is under his control. I don't send a unit in to Configuration Management until it's ready to roll; so within that unit, I refactor at will. (We're a CMM level 3 organization.)
Amusingly enough, the only criticism I get from my boss is that I _may_ be testing too much. Literally. He's not sure, but he's a bit nervous that I might be testing outside of the needed range -- for example, testing for negative numbers when the only allowable input is positive (he hasn't read my tests, and I don't think he can even imagine tests being something he'd want to read). You should see his tests -- but that's a different story.
FreeplayTV does what you want, is completely open source (hardware design and the software it runs, currently MythTV), and you can buy a preassembled system from them for just over $300 (although it doesn't include NTSC, you have to pay ATI another $50 or so for that). Since it's based on MythTV, you can play MAME on it, and many other things.
I want a little bit more before I buy: SPDIF output, for example. But they have the basics already; the rest is coming soon.
What you're saying is pretty much standard political theory, nothing particularly new. The standard way of saying it is that "Govenment is a monopoly on violence."
Your post applies that only to the death penalty, but it really applies exactly the same to every other punitive action gov't takes -- and in the long run, all actions by gov't are punitive, since the only way to make them happen is to threaten punishment.
Is it really more civilized to murder someone collectively as a "government" because all of one's friends (fellow voters) say to do it rather than because one is angry?
Of course not -- but mass votes aren't supposed to be a part of the death penalty, anyhow. Interestingly, they are considered a part of warfare, which is an interesting distinction.
You're absolutely right -- not being able to use the highlighting and searching is a loss. Of course, using Phoenix I depend on interactive find, which is even MORE useful, but even there I miss being able to just click on a word and finding it.
On the rare occasions when I use IE (my print-server-laptop isn't fast enough to make Phoenix pleasant to use), I enjoy being able to click to find text from the googlebar. But even there, Dave's Quicksearch gets the most use.
It would be interesting if there were a way to build a toolbar or drop-down button for Moz/Phoenix which could intelligently grab words from search-like URLs which would be useful for grepping. It would possibly be even more useful if that tool could highlight them as well as finding them, but maybe I'm being greedy.
As long as I'm being greedy, I'm going to post this to DQSTTD's Sourceforge page.
Of COURSE, like any useful search utility, it defaults to Google; but unlike many others, it has a HUGE number of other engines, and lets you add as many more as you want, distinguishing what type of search you want to do by little features of your search (for example, if your "search" looks like a calculator expression, it'll just replace the expression with the answer; if your search ends with a:, it searches a dictionary instead of Google).
The neatest part? It sits in your Start bar, not in your browser window -- so it takes up less useful space, and doesn't need your browser to be open.
Oh, and it works with any browser, not just IE.
I, of course, use it almost entirely with Google -- but this seems to disprove your assertion that if someone else had a nice search bar Google wouldn't be relevant.:-)
Logging based debugging is excellent, and with a slight refinement can give HUGE benefits. Specifically, every time you want to log some debug information in a function, instead refactor the function to make all the information available via an API, and test that API in your unit tests.
As a result, your unit tests grow to express how you think your software should work; thus, later changes can be made without having to worry about violating implicit assumptions (because all the assumptions you know about are explicitly and automatically tested).
As a bonus, you don't wind up inserting print statements into the control flow, and therefore you can catch more bugs in more situations.
This has worked for me for quite a while. It gives you superb testing almost for free -- and it also has the nice side effect of teaching you better API design, since when you make a bad API you'll have to correct it later in order to debug it. (This effect isn't as nice as it is in Test Driven Design, where you can't code a bad API because your design was implemented to satisfy and already-written test).
But those aren't the important numbers; what matters is the heat generated by the high frequencies. This is why proper cooling is vital to a real gamer; not only for your system, but for your eyeballs.
First of all, that's not what I was arguing at all.
Thank you for the clarification -- I definitely misunderstood you originally. You're making a lot more sense now:-).
My example of the derived Neuron class is both a transformation and an elaboration. (The fact that a class that inherits from another class is called a 'derived' class should make it obvious that it is, in fact, a derivation.)
The difficulty to me is that arguments about this can go either way. The term 'derived class' doesn't mean much; it's a technical term, not a legal one.
However, there's a clear comparison between deriving a class and deriving (for example) a universe -- taking someone else's imaginary world and characters, and telling a story using them (possibly adding some of your own). Citing this comparison would tend to support the GPL.
On the other hand, derivation from a class is an explicit use of certain features of the class -- virtual functions, compiler features, and so on, things which are built in to the class for that purpose (even if the author didn't expect them to be used). And _use_ is unaffected by copyright law (I'm not referring to Fair Use, which actually involves copying, not just using).
The pro-GPL comparison above is discussed in literary terms (i.e. no discussion of the GPL, merely of ACTUAL known copyright law as it is applied to things like fan fiction) at Chilling Effect. In summary, I think (IANAL) that the comparison is powerful and would be used in a court of law -- of course, whether it overrode the argument of Mere Use is not clear to me (it definitely doesn't have _anything_ to do with Fair Use; any sane judge would laugh if asked whether using a Free program to make a proprietary one was Fair).
There's a very close analogy to the discussion of the TSR cases; both deal with "derived classes" (although in a different sense of the word "class"), neither one implies distribution of copyrighted material, but in both cases using the "derived" material requires use of the protected material. Reading it doesn't answer questions (as you'd expect from free legal advice), but it perhaps hints at where to look.
My free-of-charge opinion: the GPL clearly requests certain things of users (including developers), and it's clearly morally wrong to disregard the wishes of the author; I would no more take advantage of an alleged flaw in the GPL than I would violate any other license (within reason). HOWEVER, the GPL is _entirely_ vulnerable to legal criticism, and will absolutely NOT provide the protection it's being asked to when attacked by a well-funded opponent.
Any sufficiently well-paid lawyer would give you similar advice. Pay the lawyer well enough, of course, and he'll represent either side, since both are defensible; however, before you've chosen which license you're going to use, you have to be warned about even a _potential_ weakness.
I don't think anyone would reasonably claim that the above example is legal. The final program is very clearly a modified version of the first. It is a clear violation of the GPL. Clever coding and distribution does not change that.
Definitely not moral. Almost certainly legal, specifically because of the extraordinary actions. You can call it an end-run around the license; the person posting it would call it extraordinary efforts to comply with a restrictive license.
Problem #1 isn't a problem with my logic; it's a fear you have. Problem #2 is defensible, but doesn't work well with what the GPL claims to be doing as a license.
Let me comment that regardless of the GPL's claims as a license, it has a very powerful goal that's entirely separate: it's trying to destroy licenses. If the GPL actually can't apply the very simple restriction it applies, then neither can common proprietary licenses.
I love that.
However, for pragmatic reasons, I choose a license for its qualities as a license, not a tool for social change. If the GPL were a quality license as well as a tool for social change, I would use it. But it's not. Fortunately, the LGPL is both a good license and a decent (although less effective) tool for social change; that's the one I usually use.
1. Linking to an OO library and inheriting a class makes the distinction between simple use and derivation extremely fuzzy.
No, it doesn't. It's still doing the same things that I claim are legal under any license: using a predefined interface to produce an entirely new object.
If company X comes along and uses my library and implements a Neuron class with a different neuron model than the default, I say that's a derivative work. Why?
Exactly my question: why?
Because if someone found a more efficient way to do the calculations required for the default model, it would be trivial for them to produce a new library that links against mine, with enhanced performance, but no separate functionality for the end user.
That's true, but it's a total non-sequitur. The fact that you WANT it to be a derivative work, or that if it were a derivative work you'd be better off, doesn't make it a derivative work.
If proprietary wrapper libraries with enhancements of core functionality can link against GPL libraries, then virtually all OO library code distributed under the GPL is at risk.
For some definition of "at risk", yes. Exactly.
On the other hand, if I had a hypothetical math library with an object that performs operation X, linking against that library and instantiating the object probably does not count as a derivative work.
Correct. For very simple reasons which also apply to inheritance.
2. If I have an application that is distributed with several libraries that were developed specifically for use with my executable, any program that links against those libraries should be considered a derivative work regardless of the importance of the function calls being made.
In other words, your intent should be used in order to figure out how your license applies. This is valid legal reasoning, and so is your strongest point. The problem is that your intent can't be used to constrain people in illegal ways; if copyright law defines what "use" versus "derivation" is, you can't change that simply by intending to.
Once again, this is the great battle the GPL is intended for: to highlight just how stupid typical software licenses are. It's designed and intended, according to its own rationale, to fight copyright law by using it against itself.
It's just an unfortunate fact that a license designed to contradict itself isn't a very good license, although it may be a great political document.
This is because the libraries were created for technical reasons, not for distribution as general purpose libraries. It is the equivalent of linking against a function in a regular executable. The fact that the link is technically against a library that is distributed with an executable should not be viewed as an exploitable loophole in the GPL.
Again, intentions carry legal weight, but even if this were explicit it wouldn't be a legally permissible item.
Let me add one more thing: the GPL _can_ regulate distribution, so if you statically link your software, or you dynamically link but distribute the dynamic library with your software, the GPL is well within its rights to regulate the resulting composite package. You have no right to distribute if you fail to distribute according to the terms of the GPL.
You're correct about what the GPL prohibits -- but the problem is that the GPL may not have the legal power to prohibit that, since it explicitly only affects derivative works, not "use".
Linking to a library is quite arguably use, not derivation. Of course, distributing the library definitely falls under the terms of the GPL, but that doesn't make it clear that the GPL can require anything about the program being linked, only the library.
I would like to see a screenshot of why this interface is so different
I agree.
It makes me wonder.... Is this the same guy who thought all files should be arranged by association, instead of in a tree structure?
Er... I think so, but didn't you know that association is a graph structure, and graphs can be displayed as trees (minimal spanning tree)?
That would just make things SLOPPY.
It could, yes. Just like the current system can make things sloppy -- but unlike the current system, it's actually directly useful for the way things need to be done. Folders and files aren't enough; we need links as well, and links need an entirely different toolset to play with.
With an associative filesystem, you only need files and categories. Only two concepts, not three.
I sure hope this Humane interface doesn't promote sloppiness!
Read the manual -- it will allow more sloppiness than the traditional system, but will do so by providing more power. For example, all documents written in it appear as a continuous chain, always apparently open.
It won't do the same -- this one can detect multiple touches, allowing it to act as a gesture detector as well as a mouse. In other words, it augments your keyboard, not just your mouse.
Excuse me. Just like "Thou shalt not kill" is a mistranslation (murder is more accurate), so is "thou shalt not charge interest." Usury is _excessive_ interest, not interest itself. Of course, that's the English meaning -- the Hebrew meaning is completely unclear.
Well said. SW Engineers and electrical engineers share almost nothing in their mindset and working conditions with "true" engineers: chemical, civil, and so on.
This is not a fault of software engineers; if they did work like other engineers, almost no software would ever be built.
Oddly enough, he's not missing anything. You're just missing how he addresses that.
The critical point he makes is/avoid duplication/. Don't say the same thing twice -- or rather, if you've said the same thing three times, write a tool to automate the thing so that you only say it once, and the tool generates the three copies.
Javadoc give you a start at documentation, but as you say it's just an index. So, use it to generate your code index -- that's one less thing to duplicate.
Try to find ways to say things without repeating yourself. Your unit tests, for example, will express your detailed design; so don't write detailed design, just write unit tests (and write them at the time you'd write your detailed design).
Massive reviews of multiple views of the source will also work. I work at a company which uses that. I'd say that one crucial requirement is that the multiple versions not be simple duplications of each other, but rather each say something truly unique. In other words, your multiple views of the document really aren't just different views, but are actually parts of the program. Your user docs aren't just rehashing the design manual in different language; they're actually the part of the design manual which specifies how the user will see the program. The programmers and customers write a prototype of a section of the user docs before they agree to add a user-visible feature; it's called a 'use case'. Tech writers may later elaborate on it, and automatic processors may add screenshots to it, but in essence, the User Stories become a critical part of the user documentation.
I'm talking too much. I'm also being needlessly specific. You don't have to do anything specific that I've said, but take my point: in most systems, redundancy is a problem, not a solution. In some systems redundancy is useful; but even in those I would suggest that the redundancy appear as forks of the design at design time, not at multiple levels of the software process (one version in user documentation, one version in design, another version in the code, etc...). What you have if you allow that redundancy is simple chaos -- you have no solid way to prefer one version of the software to another, you just have to choose one and hope you got it right.
They've managed to essentially weasel out of their anti-trust suits by being big contributors to the government. Here it's called a campaign contribution, everywhere else it's called a bribe.
Pollyanna.
A bribe is a bribe everywhere; the difference is that in the US, bribes are considered immoral and frowned upon, so politicians have to set up other ways of getting money. (Okay, the US isn't the only place where bribes are considered immoral -- but it's in the minority.)
At least US bribe-replacements all go into politics; you pay a bribe anywhere else, and it goes into the politician's pocket.
Amusing. It's kind of like doubling the worth of your bribe -- not only do you get to influence the politician, you also get to see your money used to accomplish the goals you wanted.
But... aren't Mozilla's shortcuts the same as Phoenix's? I may be way off here... Probably am.
I guess I should mention the one really negative thing about Phoenix, IMO: it doesn't have an option to encrypt passwords and such. So don't allow it to memorise your passwords unless you don't mind them being in the open!
(I _really_ like Mozilla's password memorization -- I like being able to choose hard passwords for dumb sites and not having to keep track of them.)
Slashdot Mirror
A considerably better exploration of this topic, by a considerably better person, is found in C.S. Lewis' "The Abolition of Man".
In short, technology is not to blame in any way. People are to blame.
-Billy
Yes, the file will be just as big; however, the contents of the file will be compressible on their own, and they'll also be correlated to the contents of the lossy layers (since a wavelet will only appear in the lossless layer if a wavelet generated by the lossy layers blocked it out).
With all that said, though, I'm not confident that it's worth the time. An audio server serving a HUGE number of clients with unpredictable needs might possibly benefit from the CPU savings inherent to this, but such a server would not be legally possible right now anyhow; by the time it's possible, it's almost certain that P2P technology similar to BitTorrent will be more useful.
And my home collection won't benefit; I'd rather use the most space-efficient means, not something to save CPU power for my rare format conversions. So FLAC wins (well, right now, for me MP3 wins).
-Billy
FLAC couldn't be adapted to this, because it's intrinsically lossless; converting it to lossy would require a full conversion, might as well just re-encode it as Ogg.
HOWEVER, it's possible that Ogg could be adapted the other way, adding another layer to it to make it lossless (probably by computing the difference between the lossy result and the actual source, and compressing the resulting stream). The result would be larger and MUCH more computation-demanding to play than FLAC, but it would be lossless and peelable.
I don't have any idea how much larger or more computation-dependant it would be.
-Billy
A buddy of mine stuck a hunting arrow thru a potato (needed the spud to get an airtight seal) and fired it from his spud gun. The arrow went right thru the sheet of plywood he was aiming at...
Don't waste an arrow -- a properly built potato cannon will put the tuber through 3/4 inch plywood.
-Billy
I like the idea of writing the tests as you go along, but some of the "small" steps I've seen in examples are stupid. For example, writing the test but not completely filling in the frame work for the code of the object being tested.
Yes, that's an example of an example trying to make a point: it's very easy to run the tests, so you'll often run the tests before the code's ready to compile. In real life, this happens a lot, no matter how silly it looks in a book: it's way more expensive to put in too much functionality than it is to put in too little, since if you put in too much your tests won't complain.
BUT, you don't have to do that. The #2 rule in the Pragmatic Programmers book is "THINK!" Good advice -- don't turn your brain off.
In some ways this is just a rehash of the methodolgy of structured programming. The way I was taught to break thigns down was to write the higher level code first, and this meant writing empty functions (or functions that return a constant). After that was done, you'd go back and fill in the code in increments. This just seems to be a rehash of that idea--which seemed to get lost mess when the OO craze started.
I see what you mean, but although this provides some wonderful support for top-down programming, it's not what it is or requires. It's just as easy to start in the middle and design outwards.
-Billy
"his book Refactoring... describes his experience as a consultant refactoring medium sized software projects, and gives a lot of advice on methods for refactoring.
That's not even close to an accurate description. Refactoring describes what R. is, why it's done, what you need in order to do it, and how to do some common types.
At that point [Fowler] joined forces with Beck and formed his second reason for being well known, XP.
Even more wrong. XP was developed from the conventions and experience of a lot of Smalltalk developers over quite some time. Fowler and Beck didn't invent or develop it; they came in after it was initially publicised.
As far as I can tell, the philosophy of XP is, "Software usually ends up sucking and in need of refactoring after it has been extended too far. Why wait for it to be extended too far? Just make it suck in the first place and refactor all the time!"
That's an interesting caricature, actually. There's more truth in it than in anything else you've said. XP does say that software usually ends up sucking because it's been extended too far without refactoring; so why wait for it to be extended too far? Refactor so it won't suck NOW.
The conclusion you imply (that after the refactoring the code will suck worse) is blatantly wrong, of course -- but that's just a troll.
Perhaps a better way of looking at XP is to observe that it tries to pull the software into maintenance mode as soon as possible, and make change as cheap as possible within maintenance mode.
-Billy
So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.
... is a loser.
...hoping that your boss will allow you to refactor is a loser.
The name of the practice is either Test Driven Development or (more commonly) Test Driven Design. I think it's a bad name, because it leads to the sort of confusion you have.
The tests they're talking about ARE design, so by writing them before you write code, you are, in fact, designing before coding. The difference is twofold: first, instead of stopping the design at an arbitrary level of detail and going to some other part of the program, you continue the detailed design until it produces code for that part of the program; second, instead of writing your design in an ignorable form, you write it in a simple, immediately testable form.
Because of the first difference, you get to implement your design while it's still fresh in your head; because of the second, your implementation will be forced to match your design.
I've worked with TDD for about a year now. It's a real winner -- mainly because it makes testing a creative, constructive activity (part of design) instead of destructive gruntwork (intended to tear down parts of your program).
Waiting until you've cobbled something together that passes the test
Waiting? That's exactly the point -- you DON'T wait. You implement the solution needed to pass the test (i.e. the design) immediately, as soon as you've managed to express your design in a testable form. You get to see immediately whether or not your design is workable, before you build some other aspect of your design on it.
I've worked TDD both with and without refactoring. It works either way -- without refactoring I have to take a few more risks, code a little slower, and accept slightly lower quality overall code (i.e. it doesn't fit together quite as well; refactoring doesn't slow me down at all. The nice thing is, though, that it's not under the control of my boss, anymore than which shift key I use is under his control. I don't send a unit in to Configuration Management until it's ready to roll; so within that unit, I refactor at will. (We're a CMM level 3 organization.)
Amusingly enough, the only criticism I get from my boss is that I _may_ be testing too much. Literally. He's not sure, but he's a bit nervous that I might be testing outside of the needed range -- for example, testing for negative numbers when the only allowable input is positive (he hasn't read my tests, and I don't think he can even imagine tests being something he'd want to read). You should see his tests -- but that's a different story.
-Billy
FreeplayTV
does what you want, is completely open source (hardware design and the software it runs, currently MythTV), and you can buy a preassembled system from them for just over $300 (although it doesn't include NTSC, you have to pay ATI another $50 or so for that). Since it's based on MythTV, you can play MAME on it, and many other things.
I want a little bit more before I buy: SPDIF output, for example. But they have the basics already; the rest is coming soon.
-Billy
What you're saying is pretty much standard political theory, nothing particularly new. The standard way of saying it is that "Govenment is a monopoly on violence."
Your post applies that only to the death penalty, but it really applies exactly the same to every other punitive action gov't takes -- and in the long run, all actions by gov't are punitive, since the only way to make them happen is to threaten punishment.
Is it really more civilized to murder someone collectively as a "government" because all of one's friends (fellow voters) say to do it rather than because one is angry?
Of course not -- but mass votes aren't supposed to be a part of the death penalty, anyhow. Interestingly, they are considered a part of warfare, which is an interesting distinction.
-Billy
You're absolutely right -- not being able to use the highlighting and searching is a loss. Of course, using Phoenix I depend on interactive find, which is even MORE useful, but even there I miss being able to just click on a word and finding it.
On the rare occasions when I use IE (my print-server-laptop isn't fast enough to make Phoenix pleasant to use), I enjoy being able to click to find text from the googlebar. But even there, Dave's Quicksearch gets the most use.
It would be interesting if there were a way to build a toolbar or drop-down button for Moz/Phoenix which could intelligently grab words from search-like URLs which would be useful for grepping. It would possibly be even more useful if that tool could highlight them as well as finding them, but maybe I'm being greedy.
As long as I'm being greedy, I'm going to post this to DQSTTD's Sourceforge page.
-Billy
If you're using Windows...
:, it searches a dictionary instead of Google).
:-)
As long as you don't mind the name, Dave's Quick Search Taskbar Toolbar Deskbar rocks.
Of COURSE, like any useful search utility, it defaults to Google; but unlike many others, it has a HUGE number of other engines, and lets you add as many more as you want, distinguishing what type of search you want to do by little features of your search (for example, if your "search" looks like a calculator expression, it'll just replace the expression with the answer; if your search ends with a
The neatest part? It sits in your Start bar, not in your browser window -- so it takes up less useful space, and doesn't need your browser to be open.
Oh, and it works with any browser, not just IE.
I, of course, use it almost entirely with Google -- but this seems to disprove your assertion that if someone else had a nice search bar Google wouldn't be relevant.
Try it! It's good.
-Billy
Logging based debugging is excellent, and with a slight refinement can give HUGE benefits. Specifically, every time you want to log some debug information in a function, instead refactor the function to make all the information available via an API, and test that API in your unit tests.
As a result, your unit tests grow to express how you think your software should work; thus, later changes can be made without having to worry about violating implicit assumptions (because all the assumptions you know about are explicitly and automatically tested).
As a bonus, you don't wind up inserting print statements into the control flow, and therefore you can catch more bugs in more situations.
This has worked for me for quite a while. It gives you superb testing almost for free -- and it also has the nice side effect of teaching you better API design, since when you make a bad API you'll have to correct it later in order to debug it. (This effect isn't as nice as it is in Test Driven Design, where you can't code a bad API because your design was implemented to satisfy and already-written test).
-Billy
Spams like that are even easier to detect -- and best of all, even easier to ignore in the rare cases they make it through.
-Billy
Yes, yes. Right.
But those aren't the important numbers; what matters is the heat generated by the high frequencies. This is why proper cooling is vital to a real gamer; not only for your system, but for your eyeballs.
First of all, that's not what I was arguing at all.
:-).
Thank you for the clarification -- I definitely misunderstood you originally. You're making a lot more sense now
My example of the derived Neuron class is both a transformation and an elaboration. (The fact that a class that inherits from another class is called a 'derived' class should make it obvious that it is, in fact, a derivation.)
The difficulty to me is that arguments about this can go either way. The term 'derived class' doesn't mean much; it's a technical term, not a legal one.
However, there's a clear comparison between deriving a class and deriving (for example) a universe -- taking someone else's imaginary world and characters, and telling a story using them (possibly adding some of your own). Citing this comparison would tend to support the GPL.
On the other hand, derivation from a class is an explicit use of certain features of the class -- virtual functions, compiler features, and so on, things which are built in to the class for that purpose (even if the author didn't expect them to be used). And _use_ is unaffected by copyright law (I'm not referring to Fair Use, which actually involves copying, not just using).
The pro-GPL comparison above is discussed in literary terms (i.e. no discussion of the GPL, merely of ACTUAL known copyright law as it is applied to things like fan fiction) at Chilling Effect. In summary, I think (IANAL) that the comparison is powerful and would be used in a court of law -- of course, whether it overrode the argument of Mere Use is not clear to me (it definitely doesn't have _anything_ to do with Fair Use; any sane judge would laugh if asked whether using a Free program to make a proprietary one was Fair).
There's a very close analogy to the discussion of the TSR cases; both deal with "derived classes" (although in a different sense of the word "class"), neither one implies distribution of copyrighted material, but in both cases using the "derived" material requires use of the protected material. Reading it doesn't answer questions (as you'd expect from free legal advice), but it perhaps hints at where to look.
My free-of-charge opinion: the GPL clearly requests certain things of users (including developers), and it's clearly morally wrong to disregard the wishes of the author; I would no more take advantage of an alleged flaw in the GPL than I would violate any other license (within reason). HOWEVER, the GPL is _entirely_ vulnerable to legal criticism, and will absolutely NOT provide the protection it's being asked to when attacked by a well-funded opponent.
Any sufficiently well-paid lawyer would give you similar advice. Pay the lawyer well enough, of course, and he'll represent either side, since both are defensible; however, before you've chosen which license you're going to use, you have to be warned about even a _potential_ weakness.
I don't think anyone would reasonably claim that the above example is legal. The final program is very clearly a modified version of the first. It is a clear violation of the GPL. Clever coding and distribution does not change that.
Definitely not moral. Almost certainly legal, specifically because of the extraordinary actions. You can call it an end-run around the license; the person posting it would call it extraordinary efforts to comply with a restrictive license.
-Billy
There are two problems with this.
Problem #1 isn't a problem with my logic; it's a fear you have. Problem #2 is defensible, but doesn't work well with what the GPL claims to be doing as a license.
Let me comment that regardless of the GPL's claims as a license, it has a very powerful goal that's entirely separate: it's trying to destroy licenses. If the GPL actually can't apply the very simple restriction it applies, then neither can common proprietary licenses.
I love that.
However, for pragmatic reasons, I choose a license for its qualities as a license, not a tool for social change. If the GPL were a quality license as well as a tool for social change, I would use it. But it's not. Fortunately, the LGPL is both a good license and a decent (although less effective) tool for social change; that's the one I usually use.
1. Linking to an OO library and inheriting a class makes the distinction between simple use and derivation extremely fuzzy.
No, it doesn't. It's still doing the same things that I claim are legal under any license: using a predefined interface to produce an entirely new object.
If company X comes along and uses my library and implements a Neuron class with a different neuron model than the default, I say that's a derivative work. Why?
Exactly my question: why?
Because if someone found a more efficient way to do the calculations required for the default model, it would be trivial for them to produce a new library that links against mine, with enhanced performance, but no separate functionality for the end user.
That's true, but it's a total non-sequitur. The fact that you WANT it to be a derivative work, or that if it were a derivative work you'd be better off, doesn't make it a derivative work.
If proprietary wrapper libraries with enhancements of core functionality can link against GPL libraries, then virtually all OO library code distributed under the GPL is at risk.
For some definition of "at risk", yes. Exactly.
On the other hand, if I had a hypothetical math library with an object that performs operation X, linking against that library and instantiating the object probably does not count as a derivative work.
Correct. For very simple reasons which also apply to inheritance.
2. If I have an application that is distributed with several libraries that were developed specifically for use with my executable, any program that links against those libraries should be considered a derivative work regardless of the importance of the function calls being made.
In other words, your intent should be used in order to figure out how your license applies. This is valid legal reasoning, and so is your strongest point. The problem is that your intent can't be used to constrain people in illegal ways; if copyright law defines what "use" versus "derivation" is, you can't change that simply by intending to.
Once again, this is the great battle the GPL is intended for: to highlight just how stupid typical software licenses are. It's designed and intended, according to its own rationale, to fight copyright law by using it against itself.
It's just an unfortunate fact that a license designed to contradict itself isn't a very good license, although it may be a great political document.
This is because the libraries were created for technical reasons, not for distribution as general purpose libraries. It is the equivalent of linking against a function in a regular executable. The fact that the link is technically against a library that is distributed with an executable should not be viewed as an exploitable loophole in the GPL.
Again, intentions carry legal weight, but even if this were explicit it wouldn't be a legally permissible item.
Let me add one more thing: the GPL _can_ regulate distribution, so if you statically link your software, or you dynamically link but distribute the dynamic library with your software, the GPL is well within its rights to regulate the resulting composite package. You have no right to distribute if you fail to distribute according to the terms of the GPL.
-Billy
You're correct about what the GPL prohibits -- but the problem is that the GPL may not have the legal power to prohibit that, since it explicitly only affects derivative works, not "use".
Linking to a library is quite arguably use, not derivation. Of course, distributing the library definitely falls under the terms of the GPL, but that doesn't make it clear that the GPL can require anything about the program being linked, only the library.
-Billy
I would like to see a screenshot of why this interface is so different
I agree.
It makes me wonder.... Is this the same guy who thought all files should be arranged by association, instead of in a tree structure?
Er... I think so, but didn't you know that association is a graph structure, and graphs can be displayed as trees (minimal spanning tree)?
That would just make things SLOPPY.
It could, yes. Just like the current system can make things sloppy -- but unlike the current system, it's actually directly useful for the way things need to be done. Folders and files aren't enough; we need links as well, and links need an entirely different toolset to play with.
With an associative filesystem, you only need files and categories. Only two concepts, not three.
I sure hope this Humane interface doesn't promote sloppiness!
Read the manual -- it will allow more sloppiness than the traditional system, but will do so by providing more power. For example, all documents written in it appear as a continuous chain, always apparently open.
-Billy
It won't do the same -- this one can detect multiple touches, allowing it to act as a gesture detector as well as a mouse. In other words, it augments your keyboard, not just your mouse.
Read the page.
-Billy
usury (paying or receiving interest) is a sin,
Excuse me. Just like "Thou shalt not kill" is a mistranslation (murder is more accurate), so is "thou shalt not charge interest." Usury is _excessive_ interest, not interest itself. Of course, that's the English meaning -- the Hebrew meaning is completely unclear.
-Billy
There are only aleph-null many finite strings of words, but 2^aleph-null reals, so the finitely describable are an insignificant minority.
Interesting!
Is there a smallest positive number which cannot be finitely described?
Whoops, no, there isn't; because if there was, I just finitely described it.
So there's something wrong with your hypothesis.
-Billy
Well said. SW Engineers and electrical engineers share almost nothing in their mindset and working conditions with "true" engineers: chemical, civil, and so on.
This is not a fault of software engineers; if they did work like other engineers, almost no software would ever be built.
-Billy
Oddly enough, he's not missing anything. You're just missing how he addresses that.
/avoid duplication/. Don't say the same thing twice -- or rather, if you've said the same thing three times, write a tool to automate the thing so that you only say it once, and the tool generates the three copies.
The critical point he makes is
Javadoc give you a start at documentation, but as you say it's just an index. So, use it to generate your code index -- that's one less thing to duplicate.
Try to find ways to say things without repeating yourself. Your unit tests, for example, will express your detailed design; so don't write detailed design, just write unit tests (and write them at the time you'd write your detailed design).
Massive reviews of multiple views of the source will also work. I work at a company which uses that. I'd say that one crucial requirement is that the multiple versions not be simple duplications of each other, but rather each say something truly unique. In other words, your multiple views of the document really aren't just different views, but are actually parts of the program. Your user docs aren't just rehashing the design manual in different language; they're actually the part of the design manual which specifies how the user will see the program. The programmers and customers write a prototype of a section of the user docs before they agree to add a user-visible feature; it's called a 'use case'. Tech writers may later elaborate on it, and automatic processors may add screenshots to it, but in essence, the User Stories become a critical part of the user documentation.
I'm talking too much. I'm also being needlessly specific. You don't have to do anything specific that I've said, but take my point: in most systems, redundancy is a problem, not a solution. In some systems redundancy is useful; but even in those I would suggest that the redundancy appear as forks of the design at design time, not at multiple levels of the software process (one version in user documentation, one version in design, another version in the code, etc...). What you have if you allow that redundancy is simple chaos -- you have no solid way to prefer one version of the software to another, you just have to choose one and hope you got it right.
-Billy
They've managed to essentially weasel out of their anti-trust suits by being big contributors to the government. Here it's called a campaign contribution, everywhere else it's called a bribe.
Pollyanna.
A bribe is a bribe everywhere; the difference is that in the US, bribes are considered immoral and frowned upon, so politicians have to set up other ways of getting money. (Okay, the US isn't the only place where bribes are considered immoral -- but it's in the minority.)
At least US bribe-replacements all go into politics; you pay a bribe anywhere else, and it goes into the politician's pocket.
Amusing. It's kind of like doubling the worth of your bribe -- not only do you get to influence the politician, you also get to see your money used to accomplish the goals you wanted.
-Billy
I'm glad to hear I'm not the only one.
But... aren't Mozilla's shortcuts the same as Phoenix's? I may be way off here... Probably am.
I guess I should mention the one really negative thing about Phoenix, IMO: it doesn't have an option to encrypt passwords and such. So don't allow it to memorise your passwords unless you don't mind them being in the open!
(I _really_ like Mozilla's password memorization -- I like being able to choose hard passwords for dumb sites and not having to keep track of them.)
-Billy