Change does happen in the corporate world, it just happens slowly.
_Glacially_ slowly. Sometime around 2004, my company was looking at a possible technology it could build that would have been designed for corporate intranet helpdesks, and would have depended on some fairly low-level stuff. We'd figured we could make it work in IE5 and Mozilla 1.2, which were both old technology by then and the most popular versions of browsers, according to most stats, were even newer than these. We figured we'd be fine with most companies, so started work on development.
Our initial attempts to market it brought little interest. It was only when we started looking into it in more depth that we realised most of our potential customers were running Netscape 4, a browser that had basically (as far as the rest of us were concerned) been superceded not long after it launched seven years earlier, and which was so fundamentally broken that we knew it had no chance of ever being able to support the kind of application we were developing. The project was abandoned.
What he should have said, of course, is that in the US it was made quasi-illegal by government-backed witchhunts investigating people's private political opinions without lawful authority and pressuring large proportions of the population into withdrawing any form of cooperation with anyone found to be involved in the communist party, thus effectively substantially limiting the free speech of anyone who wished to express communist thoughts and effectively decimating the membership of the organisation whose web site you link to.
While this is not technically making it "illegal" it is the closest thing a government can do that isn't actually making it illegal, and the fact that they stopped doing it is not adequate compensation for the fact that it was done, and that the process effectively ended the possibility of left-wing politics gaining a real foothold in America for fifty years. The damage has not been undone entirely yet.
a significant cross-section of the law is still defined in an unwritten common law
All countries whose legal systems derive from the British system are in this position; the US is no exception. The US system also has the issue that the common law varies from state to state and courts may or may not decide to accept precedents set outside of their jurisdiction as they see fit, which makes the entire thing even harder to deal with.
1) block frequencies 2) wait for it to crash into wall 3) steal scraps 4) get beaten up by cops who are pissed off you wrecked their toy, while you are filming covertly 5) profit
Heck, most CPU's these days don't even give you access to the microcode level anymore anyway.
Probably because most CPUs these days don't _use_ microcode any more. Almost all instructions are implemented in fixed functions in a pipeline rather than being microcoded. Microcode went out of style with the 486.
In Win32, wParam went from 16-bit to 32-bit, but still stayed as wParam. Now in Win64, wParam is a 64-bit quantity.
A bad, inappropriate use of hungarian that should not have been allowed to stand. From the original documentation of hungarian:
"w - a word (typically 16 bits). For most purposes, this is an incorrect usage"
A word was only "typically" 16 bits, but not strictly defined to be that length. With the move to 32 bit machines, 32 bit words became de rigeur. On 64 bit machines, 64 bits is also an acceptable interpretation. But the caution that the usage is likely to be incorrect is also relevant. It points out that in this case the prefix is, basically, useless.
"l - a long (typically 32 bits). The same warnings apply to this as to w."
As is "lParam" a vague specification that means almost nothing.
In this case, the prefixes can only be interpreted as names that do not provide any useful meaning. Which given that they are being used in names of variables _whose meaning changes depending on context_ this is probably about as good as it can get.
In my experience the problem is that normally you end up seeing iCount, szName, bEnabled, fPercent, etc. None of those variable names are improved in any way by hungarian notation
I'm afraid your experience seems to be little more than a straw man, because the coders you are talking about clearly are not using hungarian as it is supposed to be used.
First, there are three errors in your hungarian variable names:
"iCount" does not mean "integer count", but "index count" which is nonsensical. "fPercent" does not mean "float percent", but "flag percent" which is similarly nonsensical. "bEnabled" does not mean "boolean enabled", but "byte enabled", which is unlikely to be what you intended.
Using hungarian without actually understanding the notation is a shortcut to pointlessly obfuscated variable names.
Secondly, even were the prefixes corrected, hungarian would not suggest using these three names (I'll come back to 'szName' in a minute). The names should be:
cWhateverItIsYoureCounting (e.g. 'cCharacters', which may be further hungarianized to simply 'cch') rpctWhateverItIsAPercentageOf (e.g. 'rpctTaskComplete') fWhateverMayOrMayNotBeEnabled (e.g. 'fAcceptUserInput')
the point here is that in this case, the prefix is subsuming the entirity of your variable names, leaving you free to be more specific in the actual names. 'c' is always a count of something, so specify what it's a count of. There isn't a predefined standard prefix for percentages, but the rules suggest defining a new prefix in this case; 'pct' is the obvious choice, and I prefix it with 'r' (for 'real') to ensure it isn't confused with being a 'p'ointer to a 'c'ount of something beginning with 't'. 'f' is always a flag, i.e. a variable that states whether something is enabled or not.
you could easily drop the sz from szName and know what type it is
First, you have to bear in mind the hungarian was developed in a group that was commonly implementing programs that used either of two different types of string -- a Pascal-style string (count of bytes followed by bytes), which was denoted by 'st', and a C-style string (bytes followed by zero terminator), which was denoted by 'sz'. In this context, the choice to use the prefix makes a lot of sense. I agree that for most people, working with only a single type of string, it is less relevant.
Awful! For one extra character you get rowPosition which is unambiguous and doesn't need to be looked up.
Not saying I agree with the position, but one of the basic rules of Hungarian is that the prefix should not make sense as an English word. The reasoning behind this is to make it clear what is prefix and what is part of the variable name proper.
In this case, 'rwPosition' I can easily tell is a row, and the reason I would want to know the row is that it is the "position" (presumably of some object I'm interested in the position of). "rowPosition" is ambiguous: is it the row of a position (as in the former case), or the position of a row (the more natural interpretation of the phrase in English)?
WTF? MS BASIC was first released for the MITS Altair, arguably the first commercial microcomputer, and IIRC launched within a month of the hardware it ran on.
You don't get any difference at all if you null out local variables. In fact, you may even confuse the JIT into thinking that the variable lifetime is larger than it actually has to be (normally, it is determined by actual usage, not by lexical scope).
Yes. But nulling fields is still critical. See, even more that you need to understand about how the memory allocation system you're using works...
Variables such as "szEmployeeName" are silly and redundant. Just call it "employeeName".
The purpose of the "sz" prefix is to distinguish a C-style string ("s with a zero terminator") from a Pascal-style string (which would be called stEmployeeName in this case, "st" simply being an abbreviation of string and having been intended to be the more common variety). In a language where either could be used, the prefix would not be redundant as there would be no easy way of telling (prior to the incorporation of type-senstive operations in IDE editors) which it was.
As a relevant example for a modern untyped language, consider what happens to your "employeeName" if we have a Name class (presumably with fields title, forenames and surname). Now, how do we distinguish between a variable that holds a string containing a name, and a variable that holds a reference to a Name instance? "employeeName" is no longer such a great variable name in this situation.
The CS kid didn't pay attention in class when they covered O(N) sorts like counting sort and radix sort. Of course, both of those run in linear time.
Neither of those were covered in any CS class I attended. Seriously; CS classes don't teach every algorithm ever invented. In fact, CS classes typically teach very few algorithms. They tend to contentrate more on the approach to take to evaluate an algorithm and see how it works. I think the only sorts we studied in any depth were bubblesort and quicksort, basically because the lecturer wanted two different examples of how to analyse complexity.
I've already seen the Java "string" + "string" example, pointing out that it is slow. SO WHAT? Unless you're putting megabytes together (which you probably shouldn't), who will notice?
It's not about the length of the strings... the problem is that creates a new StringBuffer, which creates a new char array, copies the relevant characters in, then creates a new string and returns it. New object creation is practically by definition a slow process, as it means searching for free space in the heap which almost always will not be in cache (because it isn't in active use already). Even if you're just doing "a" + "b", you're probably talking thousands of active processor cycles plus at least two or three cache misses. If this is happening in an inner loop, you're basically fucked.
I've seen programmers clobber other programmers because they were using a linked list when sorting. Not very interesting if the list only grows to 10 elements.
If your list has a max 10 elements, why use a linked list? An array is much simpler to work with...
Calling arbitrary locations in the system ROM to call utility functions (which were usually designed to be called to implement BASIC commands, the most commonly-used one being "LOAD").
The idea that there might be a new version of the machine produced in future that _had different software in its ROM_ just never occurred. Thus leaving machine vendors with the annoying situation that they were unable to upgrade their systems, because half the software out there had dependencies on the precise implementation of their ROM-loaded software.
And that's not even counting the overhead of the wrapper object itself, which is IIRC 8 bytes itself, though it depends on VM too.
It's likely to be at least 12 bytes, I think:
* Memory allocation information, needs to store size of allocation along with scratch space for the garbage collector. I would be surprised if this came to less than 4 bytes overhead. * Pointer to the object's class, 4 bytes on a 32-bit VM. * Pointer to a monitor object (for use with synchronized() blocks, wait() and notify() method calls, presumably initialized to null unless any of these are used). 4 bytes on a 32-bit VM.
As this comes to a total of 16 bytes when the actual size of the object is included, I doubt there'll be anything wasted on alignment fragmentation, although if the allocation overhead is less than the 4 bytes I've guessed at, the allocator will likely align allocations to 16-byte boundaries thus negating any savings made there.
But if you were really saving one bit per instruction and you managed to compress 7k into 5k, then that means your instructions were only 3.5 bits on average to begin with, which doesn't seem very likely. Something definitely got lost in translation there.
I imagine she's talking about the old trick of having a routine that does one thing in its original form, but you can apply a simple transformation to it and have it do something totally different. Really, really, hard to write. Impossible to debug. But such code has been written. Microsoft's Altair BASIC had a similar trick: it has a series of routines that load a particular value into an 8-bit register (a 2 byte instruction), then at the end has the opcode of a 16-bit load to a different register (a single byte of a 3 byte instruction) before the next similar routine, with the consequence that when you execute it, the 8-bit load in the next routine is effectively ignored (its machine code is loaded into a register that is discarded at the end of the sequence), thus saving the cost of a jump over the routine. So it looks something like this (using Z80 assembly rather than the Intel 8080 it was written in, because I know Z80 but not 8080):
Routine1: LD A, 1 LD HL, [operand not specified] Routine 2: LD A, 2 LD HL, [operand not specified] [...] Routine n: LD A, n JP somewhere_that_uses_the_value_in_A.
So, if you call Routine 1, you see the following instructions: LD A, 1 LD HL, some_random_number LD HL, another_random_number... JP somewhere_that_uses_the_value_in_A
But if you call Routine 2, you just see: LD A, 2 LD HL, another_random_number...
(This was probably no later than, maybe, '80/'81.) I did the same thing you did. I wrote all the software at a terminal (one of those venerable bluish-green ADM 3As)
Hold on... those things were "venerable" in the early 80s?! We had a bunch of old ADM3Es at my university back in '97, and I figured they were a little antiquated, but I never guessed they were _that_ old.
"Oh, that's a clever optimization Ted came up with. See, if you have the normal int as a parameter, Java copies the whole integer on the stack. But if you use Integer it only copies a pointer to it."
AAARGH!
The icing on the cake would be if they were running on a 64 bit system, so the pointer was actually _more_ data than the int itself...
So Wally 1 keeps clicking and staring at the screen all week and spewing things like "Unbelievable!" every 5 minutes. My curiosity gets the better of me and I ask what's happening.
Is it just me who would be_much_ more tempted to say, "You keep using that word. I don't think it means what you think it means."
(Yes, I know it's a slight misquote, but it's close enough to be really tempting...)
Do we think that would have been the case if Linux had been Apache or BSD-licensed, or would we instead see a division into deluxe IBMLinux (that works on multi-processors and new chips and 64-bit) and open Linux that scrapes along on simple 486 hardware.
I don't think so, no. There have been plenty of corporate contributions to Apache and BSD-licensed projects that have been released to the public. IBM has released Eclipse under an Apache-like license. Sun have also contributed to such projects, and have released much of their own IP under similar terms. The most important, influential companies are all aware of just how important it is to be seen to be contributing to the community. It's great PR, and it gets active feedback and involvement in their own projects. They don't need legally forcing to do this.
It's the fringe cases that I'd be more concerned about. The embedded hardware supplier who runs a customized Linux distro on their box. The people who sell bundled collections of open source apps with custom installers for end users. People like these have been reluctant to comply with the GPL, and would probably cease doing so if they didn't have to. But in the end, people like these have contributed relatively little anyway.
If you look at big companies like IBM who have really embraced OSS, they have done so precisely because of the GPL.
Which is, of course, how come when you look at big IBM open source projects like Eclipse, they decided to release it under the GPL. Oh... wait... no they didn't. Guess you're just talking crap.
Frankly I'm surprised to hear of such blatant FUD coming from someone like ESR.
It isn't FUD. Every business I've worked in in the last ten years has been wary of using GPL code in their own projects, internal or otherwise. I've even had some express concerns about using gcc as the compiler on their projects (although thirty minutes of going over the situation with their lawyer helped them relax). None have ever been bothered by the idea of using BSD or Apache licensed projects in them.
If you want business adoption of a project, particularly if you're talking about a library and/or development tool, Apache/BSD licensing is definitely the way to go. If you want to retain control, sure, GPL is better, but you have to understand that you're likely to put off at least some businesses who may otherwise adopt it.
So if I use a North American bank to execute my futures investments I can run a ponzi^w investment bank in the UK and not pay taxes. Sounds good.
No, because those futures investments are taking place in North America, so you'll have to pay North American tax on them.
The question becomes interesting when the investment is not related to something that has a geographical location, but exists only on the Internet. You'll then get interesting questions arising like "where are the servers based?"... but consider the possibilities of distributed processing here.
Not true in the slightest. Set up a company in, say, Panama, and it doesn't have to pay taxes except for profit from business conducted within Panama. Other countries (e.g. UK and I presume US) have tax rules that will take taxes on profits from trading that takes place within those countries, but if the basic work is being carried out in a virtual environment has the trading taken place in those countries? Probably not.
An offshore company dealing in a virtual world will probably never have to pay any significant chunk of taxes.
Slashdot Mirror
Change does happen in the corporate world, it just happens slowly.
_Glacially_ slowly. Sometime around 2004, my company was looking at a possible technology it could build that would have been designed for corporate intranet helpdesks, and would have depended on some fairly low-level stuff. We'd figured we could make it work in IE5 and Mozilla 1.2, which were both old technology by then and the most popular versions of browsers, according to most stats, were even newer than these. We figured we'd be fine with most companies, so started work on development.
Our initial attempts to market it brought little interest. It was only when we started looking into it in more depth that we realised most of our potential customers were running Netscape 4, a browser that had basically (as far as the rest of us were concerned) been superceded not long after it launched seven years earlier, and which was so fundamentally broken that we knew it had no chance of ever being able to support the kind of application we were developing. The project was abandoned.
O RLY?.
What he should have said, of course, is that in the US it was made quasi-illegal by government-backed witchhunts investigating people's private political opinions without lawful authority and pressuring large proportions of the population into withdrawing any form of cooperation with anyone found to be involved in the communist party, thus effectively substantially limiting the free speech of anyone who wished to express communist thoughts and effectively decimating the membership of the organisation whose web site you link to.
While this is not technically making it "illegal" it is the closest thing a government can do that isn't actually making it illegal, and the fact that they stopped doing it is not adequate compensation for the fact that it was done, and that the process effectively ended the possibility of left-wing politics gaining a real foothold in America for fifty years. The damage has not been undone entirely yet.
a significant cross-section of the law is still defined in an unwritten common law
All countries whose legal systems derive from the British system are in this position; the US is no exception. The US system also has the issue that the common law varies from state to state and courts may or may not decide to accept precedents set outside of their jurisdiction as they see fit, which makes the entire thing even harder to deal with.
"does not recognize the Special 301 process due to its lacking of reliable and objective analysis"
Actually, it's because we don't give a fuck.
Allow me translate the government-speak for you: "lacking of reliable and objective analysis" == "being full of bullshit". Does that help?
1) block frequencies
2) wait for it to crash into wall
3) steal scraps
4) get beaten up by cops who are pissed off you wrecked their toy, while you are filming covertly
5) profit
There. Finished that for you.
Heck, most CPU's these days don't even give you access to the microcode level anymore anyway.
Probably because most CPUs these days don't _use_ microcode any more. Almost all instructions are implemented in fixed functions in a pipeline rather than being microcoded. Microcode went out of style with the 486.
... I have one word : wParam.
I rest my case.
In Win32, wParam went from 16-bit to 32-bit, but still stayed as wParam. Now in Win64, wParam is a 64-bit quantity.
A bad, inappropriate use of hungarian that should not have been allowed to stand. From the original documentation of hungarian:
"w - a word (typically 16 bits). For most purposes, this is an incorrect usage"
A word was only "typically" 16 bits, but not strictly defined to be that length. With the move to 32 bit machines, 32 bit words became de rigeur. On 64 bit machines, 64 bits is also an acceptable interpretation. But the caution that the usage is likely to be incorrect is also relevant. It points out that in this case the prefix is, basically, useless.
"l - a long (typically 32 bits). The same warnings apply to this as to w."
As is "lParam" a vague specification that means almost nothing.
In this case, the prefixes can only be interpreted as names that do not provide any useful meaning. Which given that they are being used in names of variables _whose meaning changes depending on context_ this is probably about as good as it can get.
In my experience the problem is that normally you end up seeing iCount, szName, bEnabled, fPercent, etc. None of those variable names are improved in any way by hungarian notation
I'm afraid your experience seems to be little more than a straw man, because the coders you are talking about clearly are not using hungarian as it is supposed to be used.
First, there are three errors in your hungarian variable names:
"iCount" does not mean "integer count", but "index count" which is nonsensical.
"fPercent" does not mean "float percent", but "flag percent" which is similarly nonsensical.
"bEnabled" does not mean "boolean enabled", but "byte enabled", which is unlikely to be what you intended.
Using hungarian without actually understanding the notation is a shortcut to pointlessly obfuscated variable names.
Secondly, even were the prefixes corrected, hungarian would not suggest using these three names (I'll come back to 'szName' in a minute). The names should be:
cWhateverItIsYoureCounting (e.g. 'cCharacters', which may be further hungarianized to simply 'cch')
rpctWhateverItIsAPercentageOf (e.g. 'rpctTaskComplete')
fWhateverMayOrMayNotBeEnabled (e.g. 'fAcceptUserInput')
the point here is that in this case, the prefix is subsuming the entirity of your variable names, leaving you free to be more specific in the actual names. 'c' is always a count of something, so specify what it's a count of. There isn't a predefined standard prefix for percentages, but the rules suggest defining a new prefix in this case; 'pct' is the obvious choice, and I prefix it with 'r' (for 'real') to ensure it isn't confused with being a 'p'ointer to a 'c'ount of something beginning with 't'. 'f' is always a flag, i.e. a variable that states whether something is enabled or not.
you could easily drop the sz from szName and know what type it is
First, you have to bear in mind the hungarian was developed in a group that was commonly implementing programs that used either of two different types of string -- a Pascal-style string (count of bytes followed by bytes), which was denoted by 'st', and a C-style string (bytes followed by zero terminator), which was denoted by 'sz'. In this context, the choice to use the prefix makes a lot of sense. I agree that for most people, working with only a single type of string, it is less relevant.
Awful! For one extra character you get rowPosition which is unambiguous and doesn't need to be looked up.
Not saying I agree with the position, but one of the basic rules of Hungarian is that the prefix should not make sense as an English word. The reasoning behind this is to make it clear what is prefix and what is part of the variable name proper.
In this case, 'rwPosition' I can easily tell is a row, and the reason I would want to know the row is that it is the "position" (presumably of some object I'm interested in the position of). "rowPosition" is ambiguous: is it the row of a position (as in the former case), or the position of a row (the more natural interpretation of the phrase in English)?
MS BASIC was a late comer
WTF? MS BASIC was first released for the MITS Altair, arguably the first commercial microcomputer, and IIRC launched within a month of the hardware it ran on.
You don't get any difference at all if you null out local variables. In fact, you may even confuse the JIT into thinking that the variable lifetime is larger than it actually has to be (normally, it is determined by actual usage, not by lexical scope).
Yes. But nulling fields is still critical. See, even more that you need to understand about how the memory allocation system you're using works...
Variables such as "szEmployeeName" are silly and redundant. Just call it "employeeName".
The purpose of the "sz" prefix is to distinguish a C-style string ("s with a zero terminator") from a Pascal-style string (which would be called stEmployeeName in this case, "st" simply being an abbreviation of string and having been intended to be the more common variety). In a language where either could be used, the prefix would not be redundant as there would be no easy way of telling (prior to the incorporation of type-senstive operations in IDE editors) which it was.
As a relevant example for a modern untyped language, consider what happens to your "employeeName" if we have a Name class (presumably with fields title, forenames and surname). Now, how do we distinguish between a variable that holds a string containing a name, and a variable that holds a reference to a Name instance? "employeeName" is no longer such a great variable name in this situation.
The CS kid didn't pay attention in class when they covered O(N) sorts like counting sort and radix sort. Of course, both of those run in linear time.
Neither of those were covered in any CS class I attended. Seriously; CS classes don't teach every algorithm ever invented. In fact, CS classes typically teach very few algorithms. They tend to contentrate more on the approach to take to evaluate an algorithm and see how it works. I think the only sorts we studied in any depth were bubblesort and quicksort, basically because the lecturer wanted two different examples of how to analyse complexity.
I've already seen the Java "string" + "string" example, pointing out that it is slow. SO WHAT? Unless you're putting megabytes together (which you probably shouldn't), who will notice?
It's not about the length of the strings... the problem is that creates a new StringBuffer, which creates a new char array, copies the relevant characters in, then creates a new string and returns it. New object creation is practically by definition a slow process, as it means searching for free space in the heap which almost always will not be in cache (because it isn't in active use already). Even if you're just doing "a" + "b", you're probably talking thousands of active processor cycles plus at least two or three cache misses. If this is happening in an inner loop, you're basically fucked.
I've seen programmers clobber other programmers because they were using a linked list when sorting. Not very interesting if the list only grows to 10 elements.
If your list has a max 10 elements, why use a linked list? An array is much simpler to work with...
Calling arbitrary locations in the system ROM to call utility functions (which were usually designed to be called to implement BASIC commands, the most commonly-used one being "LOAD").
The idea that there might be a new version of the machine produced in future that _had different software in its ROM_ just never occurred. Thus leaving machine vendors with the annoying situation that they were unable to upgrade their systems, because half the software out there had dependencies on the precise implementation of their ROM-loaded software.
And that's not even counting the overhead of the wrapper object itself, which is IIRC 8 bytes itself, though it depends on VM too.
It's likely to be at least 12 bytes, I think:
* Memory allocation information, needs to store size of allocation along with scratch space for the garbage collector. I would be surprised if this came to less than 4 bytes overhead.
* Pointer to the object's class, 4 bytes on a 32-bit VM.
* Pointer to a monitor object (for use with synchronized() blocks, wait() and notify() method calls, presumably initialized to null unless any of these are used). 4 bytes on a 32-bit VM.
As this comes to a total of 16 bytes when the actual size of the object is included, I doubt there'll be anything wasted on alignment fragmentation, although if the allocation overhead is less than the 4 bytes I've guessed at, the allocator will likely align allocations to 16-byte boundaries thus negating any savings made there.
But if you were really saving one bit per instruction and you managed to compress 7k into 5k, then that means your instructions were only 3.5 bits on average to begin with, which doesn't seem very likely. Something definitely got lost in translation there.
I imagine she's talking about the old trick of having a routine that does one thing in its original form, but you can apply a simple transformation to it and have it do something totally different. Really, really, hard to write. Impossible to debug. But such code has been written. Microsoft's Altair BASIC had a similar trick: it has a series of routines that load a particular value into an 8-bit register (a 2 byte instruction), then at the end has the opcode of a 16-bit load to a different register (a single byte of a 3 byte instruction) before the next similar routine, with the consequence that when you execute it, the 8-bit load in the next routine is effectively ignored (its machine code is loaded into a register that is discarded at the end of the sequence), thus saving the cost of a jump over the routine. So it looks something like this (using Z80 assembly rather than the Intel 8080 it was written in, because I know Z80 but not 8080):
Routine1:
LD A, 1
LD HL, [operand not specified]
Routine 2:
LD A, 2
LD HL, [operand not specified]
[...]
Routine n:
LD A, n
JP somewhere_that_uses_the_value_in_A.
So, if you call Routine 1, you see the following instructions: ...
LD A, 1
LD HL, some_random_number
LD HL, another_random_number
JP somewhere_that_uses_the_value_in_A
But if you call Routine 2, you just see: ...
LD A, 2
LD HL, another_random_number
and so on. Really nice trick, that one.
(This was probably no later than, maybe, '80/'81.) I did the same thing you did. I wrote all the software at a terminal (one of those venerable bluish-green ADM 3As)
Hold on... those things were "venerable" in the early 80s?! We had a bunch of old ADM3Es at my university back in '97, and I figured they were a little antiquated, but I never guessed they were _that_ old.
"Oh, that's a clever optimization Ted came up with. See, if you have the normal int as a parameter, Java copies the whole integer on the stack. But if you use Integer it only copies a pointer to it."
AAARGH!
The icing on the cake would be if they were running on a 64 bit system, so the pointer was actually _more_ data than the int itself...
So Wally 1 keeps clicking and staring at the screen all week and spewing things like "Unbelievable!" every 5 minutes. My curiosity gets the better of me and I ask what's happening.
Is it just me who would be_much_ more tempted to say, "You keep using that word. I don't think it means what you think it means."
(Yes, I know it's a slight misquote, but it's close enough to be really tempting...)
Do we think that would have been the case if Linux had been Apache or BSD-licensed, or would we instead see a division into deluxe IBMLinux (that works on multi-processors and new chips and 64-bit) and open Linux that scrapes along on simple 486 hardware.
I don't think so, no. There have been plenty of corporate contributions to Apache and BSD-licensed projects that have been released to the public. IBM has released Eclipse under an Apache-like license. Sun have also contributed to such projects, and have released much of their own IP under similar terms. The most important, influential companies are all aware of just how important it is to be seen to be contributing to the community. It's great PR, and it gets active feedback and involvement in their own projects. They don't need legally forcing to do this.
It's the fringe cases that I'd be more concerned about. The embedded hardware supplier who runs a customized Linux distro on their box. The people who sell bundled collections of open source apps with custom installers for end users. People like these have been reluctant to comply with the GPL, and would probably cease doing so if they didn't have to. But in the end, people like these have contributed relatively little anyway.
If you look at big companies like IBM who have really embraced OSS, they have done so precisely because of the GPL.
Which is, of course, how come when you look at big IBM open source projects like Eclipse, they decided to release it under the GPL. Oh... wait... no they didn't. Guess you're just talking crap.
Frankly I'm surprised to hear of such blatant FUD coming from someone like ESR.
It isn't FUD. Every business I've worked in in the last ten years has been wary of using GPL code in their own projects, internal or otherwise. I've even had some express concerns about using gcc as the compiler on their projects (although thirty minutes of going over the situation with their lawyer helped them relax). None have ever been bothered by the idea of using BSD or Apache licensed projects in them.
If you want business adoption of a project, particularly if you're talking about a library and/or development tool, Apache/BSD licensing is definitely the way to go. If you want to retain control, sure, GPL is better, but you have to understand that you're likely to put off at least some businesses who may otherwise adopt it.
So if I use a North American bank to execute my futures investments I can run a ponzi^w investment bank in the UK and not pay taxes. Sounds good.
No, because those futures investments are taking place in North America, so you'll have to pay North American tax on them.
The question becomes interesting when the investment is not related to something that has a geographical location, but exists only on the Internet. You'll then get interesting questions arising like "where are the servers based?" ... but consider the possibilities of distributed processing here.
I have a pal who makes CF adapters for MSX computers, I would assume these infringe on "prior art" for FAT.
I doubt it, seeing as IIRC MS wrote the software for MSXs, so presumably they are licensed for it.
Why? All companies pay taxes.
Not true in the slightest. Set up a company in, say, Panama, and it doesn't have to pay taxes except for profit from business conducted within Panama. Other countries (e.g. UK and I presume US) have tax rules that will take taxes on profits from trading that takes place within those countries, but if the basic work is being carried out in a virtual environment has the trading taken place in those countries? Probably not.
An offshore company dealing in a virtual world will probably never have to pay any significant chunk of taxes.