Then why do you think "software" is even a word? You think it's exactly equivalent to "data", so why not just use the latter word all the time? We could have the "Data Aisle" at the computer store, contained products built by "Data Engineers".
"Anyone running Microsoft data should be careful of MSBlast and LovSan infections"
It's always possible to invent super-generic definitions that rob words of all meaning. That's what you've done.
I don't really see how 'all matter is hardware' relates to 'all digitized data is software'.
Yes, I see that. You also seem not to understand why the word "software" was even invented.
I can't remember ever seeing a patent infringement action in the US or the UK where the defendant *didn't* raise invalidity as a defence:
The set you examined is already selective. As a lawyer looking at "actions", your viewpoint has already been confined to the minority of patent disputes where out-of-court negotiations failed to reach agreement. Most patent claims reach a licensing arrangement without going before a judge; either quid-pro-quo if you've got your own patent portfolio (like IBM and Kodak), or simply getting out the checkbook if you don't.
That's a vapid overgeneralization. Ignorance has been sucessfully argued as a defence in many cases. (Shoot a man for carrying a cellphone? You were ignorant, you get off the hook!)
Patents are intended at the fore to prevent copying another's ideas. If you can strongly argue ignorance of the patent, you're on your way to demonstrating independent reinvention. Then, if the jury likes your attitude, the trial can be yours. It's a roll of the dice, and it depends on your attorney getting the jurors to focus on the meaning of the original law, rather than minutia of USPTO regulations. (It's a roll of the dice)
OTOH, any statement ending in "cannot sue them" is automatically false, because anyone can sue you for any grounds.
This is completely wrong. There are many kinds of distinctions between software and data, important for both practical and theoretical reasons. I won't take up 5 pages listing them- you can reference "Turing equivalence" in an encyclopedia to scratch the surface.
It's true that "all software is data", but the reverse doesn't hold. Do you say that "all matter is hardware"? No, because such a generalization would render the word (hard|soft)ware free of content.
By far the most common way to defend against a patent infringement action is to claim that the patent is invalid
Really? Do you have any supporting evidence? I hardly ever read of a patent's validity being challenged in court. Only the most astoundingly stupid patents ever seem to be revoked, and only if they impair major economic sectors.
5806063, the US patent on Y2K compliance, was invalidated. But it's anomalous- only because the licensing fees would've exceeded $5,000,000,000 did the court chose to strike it. (They can overlook an unjust billion-dollar loss, but not real money)
"User" being the key word. The -f argument to umount only works for root. The mainstream philosophy of "Linux on the Desktop", Mike Robertson aside, is that ordinary operations should be performed with a non-root account.
%umount/mnt/cdrom/ umount:/mnt/cdrom: device is busy % umount -f/mnt/cdrom/ umount: only root can do that
If a user without the root password sees this problem, he has one recourse:
That process is too complicated to expect of someone who just wants a computer to check email and view photos on CD-Rom. At minimum, the umount utilities (and their GUI analogs) for "Desktop Linux" distributions should present an informative hint on how to proceed when a "device is busy" message occurs. ("Couldn't eject disk. Press 'Y' to force an eject, although the following programs are still using it and might lose data:...")
This is something you *still* can't do today with Windows (or Linux for that matter).
That has been accomplished in experimental patches to Linux. (It's fairly easy to write a daemon which detects mounting of a new volume and creates a symlink to it, using the name of the disk)
However, for it to work well, applications would have to be modified (but only rarely, and in small amounts). I don't think the Linux community is willing enough to break from traditions to give this a real try.
There's the Unix tradition to adhere to ("Filesystems never go away. Ever."). But more importantly, they can't stray from the behavior of Microsoft Windows(tm). The developers interested in boosting Linux on the desktop are trying to draw in Windows(tm) users. Those users are accustomed to "drive A is the top, drive D is the bottom". Deviation from that system might be viewed as a needless complication.
Like MS-Word's internal format, yeah, rii-ight... (-: Not the "internal" format. The friendly, pixelized one it displays on your screen. With the colors and fonts, and the borders and shading... You know, with the anthropomorphic paperclip on the side?
Anyhoo, I'd like to see the higher-level description that produced this. (-:
That's one of the "aberrations" I mentioned. Yes, some random weirdos write postscript manually. The same way that some people compose their own binary code for obselete processors.
But the thread was talking about a language that was used millions of times per year. Manually-crafted postscript doesn't reach that level, but machine-generated PS is created a million times daily. The common variety of postscript is neither written nor read by a human.
Postscript is no more "written" than 386 machine code. Both are generated by a computer processing a higher-level description that is more amenable to human understanding. (Rare tinkerers can manually create the low level code, but they are abberations)
Some aspects of postscript (or any powerful graphical description language) seem very tree-like. Particularly the system of pushing transformations onto a stack. A human reading a postscript file can visualize the tree formed by the transformation stack over time, just like a C program represents a function-call tree over time.
On the message board you link to, I find you mention that "in order for a language to be concatenative, it must be true that any single program can be split at any token boundary to produce two valid programs."
I don't see how postscript meets this criteria. I'm not an expert, but if a postscript stream ended in "pop" and you split off just that last token, you'd have an invalid program.
(One might argue that a "stackunderflow" is just an error, and not a sign of an invalid program. But underflows are logical errors, unlike overflows which may be resource overruns, and resemble strongly an invalid program. But from a standpoint of software linguistics, {return *(int*)0;} is a valid C function body, although it cannot help but produce a logical error on execution)
But DNA isn't a computer language because it's not for computers, and machine code isn't a computer language because it's not a language.
You didn't say "computer language", you said "programming language". A slippery person can claim DNA is a "program" (defining program to be "a pre-arranged sequence of actions"). You could also make silly justifications for many kinds of formalized human communication to be "programs".
However, since you consider even assembly-code to be tree-like (I don't agree, because the "trees" making an opcode are of fixed height), you'd probably also see trees in any human language (starting with sentence-diagrams)
A human can write any of these languages, including the one to which I was referring with the hint you're talking about.
But anyhow, use any word you like if you don't like "written". Composed? "Designed" doesn't work.
By the time it gets used, major software like Photoshop or Linux is machine code. But to say it was "written in machine code" is obviously incorrect. They were written in C/C++. If you're not talking about machinecode though, my comment was irrelevant.
Source code for most programming languages is a tree, not a linear list;
The source code is a linearization of a tree structure which retains enough nesting data to permit the compiler to unambiguously reconstruct the tree itself.
I personally prefer IDEs that are smart enough to be aware of the tree-nature, not just the token-list format. However, an editor which only understands the "2d character array" represenation of the code (necesitating horizontal scrolling) is the worst.
Let me give a little hint for one of the possible answers: probably more programs are written in this language every day than all the other languages combined, but normally no human writes them and no human reads them.
You could mean either machine code, or deoxyribonucleic acid. Both of them are low level ("compiled") programs that are linearly traversed by a stateful read-head. Humans hardly ever look at that code. However, claiming "more programs are written in this language" seems a stretch, as I don't consider an activity "writing" without an intelligence behind it.
One who believes in Jakob Nielsen could argue that when a user sees 2 scrollbars around a website, two separate parties have made errors.
First, the web designer miscalulated of course... but then, the programmer of the web-browser neglected to correct it!
A programmer, if he wants, can find a way to linearize any document so that the user sees it in vertically separated chunks. (How much damage this does to the semantic content of the original will vary).
Opera already has this feature, although I'm not sure if it activates except on very narrow screens.
Since a typical monitor can display 200+ characters on a line, I truely hope you don't need to scroll horizontally through source code!
Source code for every programming language (aside from intentionally difficult ones) is meant as an intermediate representation to a linear list of symbols. linear. One-dimensional.
Logically, a program is only backwards/forwards. A programmer should always be able to think of navigating through code in this way (or at an even higher level of abstaction, with a fancy IDE).
I pity anyone who scrolls right to read the end of a long function call, and then back right to see what happens on the next line. (There's also the ROTT against deeply nesting within one function body...)
I too was suprised to see that Boies was on contingency. I'd assumed he was a marquee name brought in on a high hourly retainer to lend credibility to a weak claim.
It's completely simple. (So obvious that maybe I didn't think I needed to explain). Note that claiming your "developers are long experienced with GPL development" is irrelevant. It's not the development that's a violation, but the distribution. I think it's not an Opie guy who's doing it, but the OpenZaurus people (I haven't checked which group you belong to)
Go to the OpenZaurus download page: http://www.openzaurus.org/oz_website/conten t/downl oad
Do you see binaries?Yes, called "Kernel Images" Are those binaries made from modified GPL code?Yes, the Linux kernel code Do you see a link to download the source used to make those binaries?No Inside the binaries, do you find "An offer to recieve the source code, valid for 3 years to any 3rd party"?No
Those facts add up to a GPL violation. If you release binaries based on something GPL, you must provide the source code you used to make them. You can do it either by download from the same place the executables come from, or by including an offer to mail them later.
You must provide the source for the EXACT version of the binaries. And you must provide ALL the source- not just a patch against some other version of the code.
OpenZaurus provides patches, which, if you applied to the precisely correct versions of source code from elsewhere, would produce a binary resembling the one up for download, but not quite identical.
This is not sufficient to comply with the GPL. It's not only a legal problem, but a practical one. The OpenZaurus "buildroot" is quite difficult to compile, because the upstream software it's based on frequently changes so that patches don't apply cleanly.
According to RMS, the violation is "well-meaning", but still illegal.
Maybe you would like to contribute with detailed ideas instead of flames ? (Someone else responding to the question)
I've contributed detailed ideas before, but they were ignored. Now I'd like to contribute patches. However, I have a Zaurus 5500, meaning OpenZaurus would be the natural thing for me to start developing from (rather than trying to install Opie on a sharp rom)
But I refuse to work on a project that is distributed in violation of the GPL.
I understand that Opie and OZ are different projects with different managers, but they do share some people and code. I see that the OZ maintainer frequently commits to opie cvs. His violations don't reflect well on your project.
Many people have given you excellent reasons, but they skipped one: Compatibility.
With USB storage, you can be virtually assured that wandering up to a strange computer will allow you to load the files. Firewire isn't common enough for that to be a safe assumption.
To a person who wants a PDA, they don't give a hoot if the thing isn't doing job X at the most blindingly fast possible speed, if it can do jobs Y, Z, alpha and omega for them as well.
Wrong. Customers looking for a PDA are actually more sensitive to performance than PC buyers. When you're digging a PDA from your jacket to check an airline schedule as you haul an approved-size carryon in each hand, you do not want to wait 12 seconds to start the app and then 5 more sec for each button-press to register.
The continued dominance of the Palm-style PDAs (over PocketPC or Zaurus models) is that they avoid adding fancy features to maintain fast, predictable performance.
Sounds scarily also like the Amiga.
The Amiga was high-performing, but also bloated with features. Most users (and remember, corporate customers had the most cash to spend on desktop PCs) didn't want to pay for things like HAM, Genlocking, or Bob Coppers. (They probably didn't even know what those were)
The Amiga wasn't late to market- it was early. Commodore tried to sell integrated, full-colour GUI desktops long before there was consumer demand.
A commercially-released Palmtop already had X11 as it's native GUI: The Agenda VR3.
The device was puny and slow, but X wasn't the major bottleneck. The X files probably occupied a few 100K more space than a slimmer library would've needed, though (since after all it included TCP communication functionality, unlike the competition). Those features were quite handy. You could plug the PDA into a PC and then run the addressbook software on your larger monitor (the windows would scale up correctly). Or for software development, you could cross-compile an app and immediately test it on the small screen without transmitting the executable to the PDA's storage.
In comparison to that weak old hardware, a modern Zaurus or Ipaq has plenty of horsepower to run X as the main interface.
I know I am going to get a troll or an offtopic... but I just don't understand the point of the KDE project at all. Prehaps because I am not cool enough to use a workstation/PC... I use notebooks or paper on my desk for the things I reall, really...really need. Good thing I don't have a lot of them.
All of this equipment already ships with an OS that works and that was custom designed for that piece of hardware...so why rebuild it with linux?
The same is true of a desktop PC.
But palm/etc does not charge me extra for the use of their palm os.
This is incorrect. All manufactures of Palm hardware (even Palm itself!) buy the OS from a separate company, and roll the price into what you pay for the PDA. This is EXACTLY how PC vendors deal with Microsoft.
the guys that want you to sign over your copyrights so they can defend them for you. I guess they spent my donation money on pizza and Bawls, because they haven't done much here.
The FSF isn't an author of Linux. Few (if any?) Linux contributors assigned copyright to the FSF. They're a third party here- what would you expect them to do?
The most the FSF could offer against SCO would be a friend-of-court brief. And I'm sure they'll produce one when the time comes.
The FSF lawyer has already published articles attacking the validity of SCO's claims, so they're already helping some.
I would really appreciate a chance to throw my slides your way for a further reality check (and discussion) before I get pelted by tomatoes Tuesday;)
I wouldn't be a useful reviewer. With previous knowledge of M&S buzzwords, I'm non-representative of a Linuxworld attendee. For that kind of audience, I can only suggest you bring lots of exciting screenshots and make videogame analogies.
Quickly pointing out a relevant project you might already be aware of: SAF on Scalable Parallel Processors. That experiment was notable for how much it avoided using the APIs typically used for cluster computing. (There's no MPI or Beowulf, for example)
that HLA is not just about updating object state data during gameplay - it can also be used to setup of the initial rules regarding object interaction
Well, the biggest difference between HLA and DIS, after all, is that HLA is fully generic and makes no assumptions about the subject being simulated. (Whereas DIS only works if you have vehicles shooting at each other, the arbitrary attribute-definitions of HLA allow it to represent cardiovascular blood-flow or thermal conductivity just as easily). DIS came with its own set of rules for object interactions. While this limits the standard's reusablity, it makes it more useful as a target for compatibility. If two programs use DIS, you can be sure they will make general sense when plugged together. But knowing that two systems use HLA tells you nothing about their prospects for interoperability.
So, any statement of the form "HLA can XXX" is trivially true. (Well, unless you go into the weeds... standards-compliant HLA cannot emulate DIS, for example)
they were the first one to achieve integration between live, virtual, and constructive simulations - something that has (to my knowledge) evaded Millenium Challenge.
The eetimes article mentions nothing about LVC integration... I suppose you have another data source.
Live and virtual are easy to combine- this has been done at least since 1980s SimNET at Knox. Adding in "constructive" is trickier, and arguably impossible. You can pack a constructive sim into a virtual framework... but at that point, is it really constructive anymore? The guarrantees normally provided by constructive sim are broken if it's accepting input from live players. I'd call that "code reuse from constructive models into a virtual sim project".
The list of software used in MC02 is long (40+ programs?) and I don't recognize all the names. However, if any one of them had been initially designed for constructive execution, one could say that MC02 had already achieved LVC.
(Note that the only real goal of MC02 was to achieve simulation interoperability milestones, and not to actually gain insight into future combat strategies. It was too haphazard to draw conclusions from)
As a result, Linux is special (but not necessarily unique) because of lower initial cost, multiple platform capability, and because of the Open Source development support that surrounds it.
Linux is still only marginally successful in the wargaming arena. Both traditional big-iron UNIX and desktop Microsoft Windows are still strong competitors (it pains me every time I watch a venerable M&S be ported to Windows, but the customers demand it). Most of Linux's success comes at the expense of more costly Unixes. The free development tools are nice, but not a major factor to DoD customers (they care more about recurring deployment costs than one-off development expenses)
Offtopic, there is an interesting article regarding "Open Source" development and wargaming. The article is funny to read, because it's so completely wrong- the author wasn't even using a valid definition of "Open Source". The ModSAF program he refers to was only "Open Source" as much as Minix was (all changes must be sent to the project originator), and we all know what happened to Minix.
Slashdot Mirror
All software is data and all data is software.
Then why do you think "software" is even a word? You think it's exactly equivalent to "data", so why not just use the latter word all the time? We could have the "Data Aisle" at the computer store, contained products built by "Data Engineers".
"Anyone running Microsoft data should be careful of MSBlast and LovSan infections"
It's always possible to invent super-generic definitions that rob words of all meaning. That's what you've done.
I don't really see how 'all matter is hardware' relates to 'all digitized data is software'.
Yes, I see that. You also seem not to understand why the word "software" was even invented.
I can't remember ever seeing a patent infringement action in the US or the UK where the defendant *didn't* raise invalidity as a defence:
The set you examined is already selective. As a lawyer looking at "actions", your viewpoint has already been confined to the minority of patent disputes where out-of-court negotiations failed to reach agreement. Most patent claims reach a licensing arrangement without going before a judge; either quid-pro-quo if you've got your own patent portfolio (like IBM and Kodak), or simply getting out the checkbook if you don't.
The FLTK library mentioned is intended to be statically linked into applications.
Wrong. Ignorance is no defense before law.
That's a vapid overgeneralization. Ignorance has been sucessfully argued as a defence in many cases. (Shoot a man for carrying a cellphone? You were ignorant, you get off the hook!)
Patents are intended at the fore to prevent copying another's ideas. If you can strongly argue ignorance of the patent, you're on your way to demonstrating independent reinvention. Then, if the jury likes your attitude, the trial can be yours. It's a roll of the dice, and it depends on your attorney getting the jurors to focus on the meaning of the original law, rather than minutia of USPTO regulations. (It's a roll of the dice)
OTOH, any statement ending in "cannot sue them" is automatically false, because anyone can sue you for any grounds.
This is completely wrong. There are many kinds of distinctions between software and data, important for both practical and theoretical reasons. I won't take up 5 pages listing them- you can reference "Turing equivalence" in an encyclopedia to scratch the surface.
It's true that "all software is data", but the reverse doesn't hold. Do you say that "all matter is hardware"? No, because such a generalization would render the word (hard|soft)ware free of content.
By far the most common way to defend against a patent infringement action is to claim that the patent is invalid
Really? Do you have any supporting evidence? I hardly ever read of a patent's validity being challenged in court. Only the most astoundingly stupid patents ever seem to be revoked, and only if they impair major economic sectors.
5806063, the US patent on Y2K compliance, was invalidated. But it's anomalous- only because the licensing fees would've exceeded $5,000,000,000 did the court chose to strike it. (They can overlook an unjust billion-dollar loss, but not real money)
"User" being the key word. The -f argument to umount only works for root. The mainstream philosophy of "Linux on the Desktop", Mike Robertson aside, is that ordinary operations should be performed with a non-root account.
umount:
% umount -f
umount: only root can do that
If a user without the root password sees this problem, he has one recourse:
tcsh 30573 kirai cwd DIR 11,0 2048 57344
% kill 30573
%umount
umount:
% lsof | grep cdrom
tcsh 30573 kirai cwd DIR 11,0 2048 57344
% kill -9 30573
% umount
That process is too complicated to expect of someone who just wants a computer to check email and view photos on CD-Rom. At minimum, the umount utilities (and their GUI analogs) for "Desktop Linux" distributions should present an informative hint on how to proceed when a "device is busy" message occurs. ("Couldn't eject disk. Press 'Y' to force an eject, although the following programs are still using it and might lose data:...")
This is something you *still* can't do today with Windows (or Linux for that matter).
That has been accomplished in experimental patches to Linux. (It's fairly easy to write a daemon which detects mounting of a new volume and creates a symlink to it, using the name of the disk)
However, for it to work well, applications would have to be modified (but only rarely, and in small amounts). I don't think the Linux community is willing enough to break from traditions to give this a real try.
There's the Unix tradition to adhere to ("Filesystems never go away. Ever."). But more importantly, they can't stray from the behavior of Microsoft Windows(tm). The developers interested in boosting Linux on the desktop are trying to draw in Windows(tm) users. Those users are accustomed to "drive A is the top, drive D is the bottom". Deviation from that system might be viewed as a needless complication.
Like MS-Word's internal format, yeah, rii-ight... (-:
Not the "internal" format. The friendly, pixelized one it displays on your screen. With the colors and fonts, and the borders and shading... You know, with the anthropomorphic paperclip on the side?
Anyhoo, I'd like to see the higher-level description that produced this. (-:
That's one of the "aberrations" I mentioned. Yes, some random weirdos write postscript manually. The same way that some people compose their own binary code for obselete processors.
But the thread was talking about a language that was used millions of times per year. Manually-crafted postscript doesn't reach that level, but machine-generated PS is created a million times daily. The common variety of postscript is neither written nor read by a human.
Postscript is no more "written" than 386 machine code. Both are generated by a computer processing a higher-level description that is more amenable to human understanding. (Rare tinkerers can manually create the low level code, but they are abberations)
Some aspects of postscript (or any powerful graphical description language) seem very tree-like. Particularly the system of pushing transformations onto a stack. A human reading a postscript file can visualize the tree formed by the transformation stack over time, just like a C program represents a function-call tree over time.
On the message board you link to, I find you mention that "in order for a language to be concatenative, it must be true that any single
program can be split at any token boundary to produce two valid programs."
I don't see how postscript meets this criteria. I'm not an expert, but if a postscript stream ended in "pop" and you split off just that last token, you'd have an invalid program.
(One might argue that a "stackunderflow" is just an error, and not a sign of an invalid program. But underflows are logical errors, unlike overflows which may be resource overruns, and resemble strongly an invalid program. But from a standpoint of software linguistics, {return *(int*)0;} is a valid C function body, although it cannot help but produce a logical error on execution)
But DNA isn't a computer language because it's not for computers, and machine code isn't a computer language because it's not a language.
You didn't say "computer language", you said "programming language". A slippery person can claim DNA is a "program" (defining program to be "a pre-arranged sequence of actions"). You could also make silly justifications for many kinds of formalized human communication to be "programs".
However, since you consider even assembly-code to be tree-like (I don't agree, because the "trees" making an opcode are of fixed height), you'd probably also see trees in any human language (starting with sentence-diagrams)
A human can write any of these languages, including the one to which I was referring with the hint you're talking about.
But anyhow, use any word you like if you don't like "written". Composed? "Designed" doesn't work.
By the time it gets used, major software like Photoshop or Linux is machine code. But to say it was "written in machine code" is obviously incorrect. They were written in C/C++. If you're not talking about machinecode though, my comment was irrelevant.
Source code for most programming languages is a tree, not a linear list;
The source code is a linearization of a tree structure which retains enough nesting data to permit the compiler to unambiguously reconstruct the tree itself.
I personally prefer IDEs that are smart enough to be aware of the tree-nature, not just the token-list format. However, an editor which only understands the "2d character array" represenation of the code (necesitating horizontal scrolling) is the worst.
Let me give a little hint for one of the possible answers: probably more programs are written in this language every day than all the other languages combined, but normally no human writes them and no human reads them.
You could mean either machine code, or deoxyribonucleic acid. Both of them are low level ("compiled") programs that are linearly traversed by a stateful read-head. Humans hardly ever look at that code. However, claiming "more programs are written in this language" seems a stretch, as I don't consider an activity "writing" without an intelligence behind it.
One who believes in Jakob Nielsen could argue that when a user sees 2 scrollbars around a website, two separate parties have made errors.
First, the web designer miscalulated of course... but then, the programmer of the web-browser neglected to correct it!
A programmer, if he wants, can find a way to linearize any document so that the user sees it in vertically separated chunks. (How much damage this does to the semantic content of the original will vary).
Opera already has this feature, although I'm not sure if it activates except on very narrow screens.
Since a typical monitor can display 200+ characters on a line, I truely hope you don't need to scroll horizontally through source code!
Source code for every programming language (aside from intentionally difficult ones) is meant as an intermediate representation to a linear list of symbols. linear. One-dimensional.
Logically, a program is only backwards/forwards. A programmer should always be able to think of navigating through code in this way (or at an even higher level of abstaction, with a fancy IDE).
I pity anyone who scrolls right to read the end of a long function call, and then back right to see what happens on the next line. (There's also the ROTT against deeply nesting within one function body...)
From what I've seen and heard, David Boies does not work on contingency.
You've heard wrong.
I too was suprised to see that Boies was on contingency. I'd assumed he was a marquee name brought in on a high hourly retainer to lend credibility to a weak claim.
Go to the OpenZaurus download page:
http://www.openzaurus.org/oz_website/conte
- Do you see binaries? Yes, called "Kernel Images"
Those facts add up to a GPL violation. If you release binaries based on something GPL, you must provide the source code you used to make them. You can do it either by download from the same place the executables come from, or by including an offer to mail them later.Are those binaries made from modified GPL code? Yes, the Linux kernel code
Do you see a link to download the source used to make those binaries? No
Inside the binaries, do you find "An offer to recieve the source code, valid for 3 years to any 3rd party"? No
You must provide the source for the EXACT version of the binaries. And you must provide ALL the source- not just a patch against some other version of the code.
OpenZaurus provides patches, which, if you applied to the precisely correct versions of source code from elsewhere, would produce a binary resembling the one up for download, but not quite identical.
This is not sufficient to comply with the GPL. It's not only a legal problem, but a practical one. The OpenZaurus "buildroot" is quite difficult to compile, because the upstream software it's based on frequently changes so that patches don't apply cleanly.
According to RMS, the violation is "well-meaning", but still illegal.
Maybe you would like to contribute with detailed ideas instead of flames ?
(Someone else responding to the question)
I've contributed detailed ideas before, but they were ignored. Now I'd like to contribute patches. However, I have a Zaurus 5500, meaning OpenZaurus would be the natural thing for me to start developing from (rather than trying to install Opie on a sharp rom)
But I refuse to work on a project that is distributed in violation of the GPL.
I understand that Opie and OZ are different projects with different managers, but they do share some people and code. I see that the OZ maintainer frequently commits to opie cvs. His violations don't reflect well on your project.
Many people have given you excellent reasons, but they skipped one: Compatibility.
With USB storage, you can be virtually assured that wandering up to a strange computer will allow you to load the files. Firewire isn't common enough for that to be a safe assumption.
GN:
"site": I think you meant "cite". Neither should be confused with "sight".
"plagiarism": No, plagiarism is an attempt to mislead about authorship, not merely an omission of attribution.
To a person who wants a PDA, they don't give a hoot if the thing isn't doing job X at the most blindingly fast possible speed, if it can do jobs Y, Z, alpha and omega for them as well.
Wrong. Customers looking for a PDA are actually more sensitive to performance than PC buyers. When you're digging a PDA from your jacket to check an airline schedule as you haul an approved-size carryon in each hand, you do not want to wait 12 seconds to start the app and then 5 more sec for each button-press to register.
The continued dominance of the Palm-style PDAs (over PocketPC or Zaurus models) is that they avoid adding fancy features to maintain fast, predictable performance.
Sounds scarily also like the Amiga.
The Amiga was high-performing, but also bloated with features. Most users (and remember, corporate customers had the most cash to spend on desktop PCs) didn't want to pay for things like HAM, Genlocking, or Bob Coppers. (They probably didn't even know what those were)
The Amiga wasn't late to market- it was early. Commodore tried to sell integrated, full-colour GUI desktops long before there was consumer demand.
X? On a palmtop? Talk about missing the mark.
A commercially-released Palmtop already had X11 as it's native GUI: The Agenda VR3.
The device was puny and slow, but X wasn't the major bottleneck. The X files probably occupied a few 100K more space than a slimmer library would've needed, though (since after all it included TCP communication functionality, unlike the competition). Those features were quite handy. You could plug the PDA into a PC and then run the addressbook software on your larger monitor (the windows would scale up correctly). Or for software development, you could cross-compile an app and immediately test it on the small screen without transmitting the executable to the PDA's storage.
In comparison to that weak old hardware, a modern Zaurus or Ipaq has plenty of horsepower to run X as the main interface.
I know I am going to get a troll or an offtopic... but I just don't understand the point of the KDE project at all. Prehaps because I am not cool enough to use a workstation/PC... I use notebooks or paper on my desk for the things I reall, really...really need. Good thing I don't have a lot of them.
All of this equipment already ships with an OS that works and that was custom designed for that piece of hardware...so why rebuild it with linux?
The same is true of a desktop PC.
But palm/etc does not charge me extra for the use of their palm os.
This is incorrect. All manufactures of Palm hardware (even Palm itself!) buy the OS from a separate company, and roll the price into what you pay for the PDA. This is EXACTLY how PC vendors deal with Microsoft.
the guys that want you to sign over your copyrights so they can defend them for you. I guess they spent my donation money on pizza and Bawls, because they haven't done much here.
The FSF isn't an author of Linux. Few (if any?) Linux contributors assigned copyright to the FSF. They're a third party here- what would you expect them to do?
The most the FSF could offer against SCO would be a friend-of-court brief. And I'm sure they'll produce one when the time comes.
The FSF lawyer has already published articles attacking the validity of SCO's claims, so they're already helping some.
I would really appreciate a chance to throw my slides your way for a further reality check (and discussion) before I get pelted by tomatoes Tuesday ;)
I wouldn't be a useful reviewer. With previous knowledge of M&S buzzwords, I'm non-representative of a Linuxworld attendee. For that kind of audience, I can only suggest you bring lots of exciting screenshots and make videogame analogies.
Quickly pointing out a relevant project you might already be aware of: SAF on Scalable Parallel Processors. That experiment was notable for how much it avoided using the APIs typically used for cluster computing. (There's no MPI or Beowulf, for example)
augmos.com
There seems to be a disparity between the violence inherent to military projects and Augmos's more gentle social goals like "learning therapy"...
(I guess you're just in it for the Linux aspect. Pentagon consulting can be a great revenue stream!)
that HLA is not just about updating object state data during gameplay - it can also be used to setup of the initial rules regarding object interaction
Well, the biggest difference between HLA and DIS, after all, is that HLA is fully generic and makes no assumptions about the subject being simulated. (Whereas DIS only works if you have vehicles shooting at each other, the arbitrary attribute-definitions of HLA allow it to represent cardiovascular blood-flow or thermal conductivity just as easily). DIS came with its own set of rules for object interactions. While this limits the standard's reusablity, it makes it more useful as a target for compatibility. If two programs use DIS, you can be sure they will make general sense when plugged together. But knowing that two systems use HLA tells you nothing about their prospects for interoperability.
So, any statement of the form "HLA can XXX" is trivially true. (Well, unless you go into the weeds... standards-compliant HLA cannot emulate DIS, for example)
they were the first one to achieve integration between live, virtual, and constructive simulations - something that has (to my knowledge) evaded Millenium Challenge.
The eetimes article mentions nothing about LVC integration... I suppose you have another data source.
Live and virtual are easy to combine- this has been done at least since 1980s SimNET at Knox. Adding in "constructive" is trickier, and arguably impossible. You can pack a constructive sim into a virtual framework... but at that point, is it really constructive anymore? The guarrantees normally provided by constructive sim are broken if it's accepting input from live players. I'd call that "code reuse from constructive models into a virtual sim project".
The list of software used in MC02 is long (40+ programs?) and I don't recognize all the names. However, if any one of them had been initially designed for constructive execution, one could say that MC02 had already achieved LVC.
(Note that the only real goal of MC02 was to achieve simulation interoperability milestones, and not to actually gain insight into future combat strategies. It was too haphazard to draw conclusions from)
As a result, Linux is special (but not necessarily unique) because of lower initial cost, multiple platform capability, and because of the Open Source development support that surrounds it.
Linux is still only marginally successful in the wargaming arena. Both traditional big-iron UNIX and desktop Microsoft Windows are still strong competitors (it pains me every time I watch a venerable M&S be ported to Windows, but the customers demand it). Most of Linux's success comes at the expense of more costly Unixes. The free development tools are nice, but not a major factor to DoD customers (they care more about recurring deployment costs than one-off development expenses)
Offtopic, there is an interesting article regarding "Open Source" development and wargaming. The article is funny to read, because it's so completely wrong- the author wasn't even using a valid definition of "Open Source". The ModSAF program he refers to was only "Open Source" as much as Minix was (all changes must be sent to the project originator), and we all know what happened to Minix.