The RIAA with their sue-grandma stories sure look like they're really a bunch of jerks.
Get real. You've fallen for the Slashdot propaganda.
No, I paraphrased the "slashdot propaganda". But it's not just slashdot's propaganda, these stories have appeared on other websites, newspaers, etc.
Again, this is not my view, but it is factual that these stories were broadly dissemenated.
Also, I don't give two hoots if slashdot was biased. Someone raised an issue as if they were pointing out hypocracy, when it's really quite consistent simple human behavior.
It's quite simple. People like to dump on the no-good-shits of the world. They like them clearly delineated and then they like to dump on them.
This allows them to feel better because they are part of a group, and clearly better than the target.
The RIAA with their sue-grandma stories sure look like they're really a bunch of jerks. So people dump on them. These people who appropriated a bunch of work that wasn't theirs are obviously a bunch of greedy bastards, so we dump on them too!
It's really not about the relative worth of the PearPC folks or the RIAA targets, but the clear-cut moral inadequacy of the party we get to therefore despise.
apbuild only seems to cover libc issues, not issues with other libraries. Do you plan to cover all library interface changes?
For example, my distribution (debian) contains package names like libpng12, indicating that this particular package has gone through a total of 12 binary-incompatable interfaces changes. libpth is at version 14, and libcrypto++, for example, is apparently binary-incompatable with every release.
Other distributions do not even bother to rename for binary incompatabilities consistently.
Normally, my package maintainer gets the code from Trustworthy Tim by hand, inspects it by hand, cryptographically signs it by hand, and uploads it him/herself to the package repository where it is centrally managed without access from Evil Edward.
Autopackage provides a way for me to automate the setup and install, right? or wrong? If the autopackage automates dependencies, then it's an attack vector for spyware. If it doesn't automate dependencies, then it doesn't meet the described criteria for helping users.
At 63724 bytes, it's less than a third of the binary size of mwm that you quote, and it doesn't link against any huge bloated and unpleasant motif library. In fact, it only uses libXext, and X11 on top of the usual stdc++, libm, libgcc, libc, libdl and ld-linux. in-memory size can be as little as 10k malloced on top of the 60k image.
How does autopackage allow me to authenticate that the provider of the autopackage is in fact the upstream software author Trustworthy Tim, and not Evil Patrick the Spyware Maven?
In case this isn't clear enough, assume that the upstream author Trustworthy Tim has never heard of or considered using autopackage.
Every time autopackage gets mentioned, I look into it, only to come away lost as to what problem the project is trying to solve.
It claims to provide binary packages which will install on any distribution, but I don't see any sort of information about how the project plans to address the fact that binary interfaces on linux systems are moderately unstable. It just seems quixotic.
More or less, writing viruses is legal, but writing viruses and releasing them is illegal.
Just writing it might be illegal in a court if they could convince a jury you intended to release it. That might be tricky since there is a history of people writing such things for nonrelease, and a subset that got out accidentally.
It spends a lot of time discussing what really happens in various situations and asserting that some theories that have been promoted are maybe incorrect, but does no investigative research.
Moreover, all these performance claims are bandied about, and yet I see no benchmarking.
I have building an application in mono which shall remain nameless over the last six months.
I've encountered troubling issues in the following areas:
Runtime problems (interprocess communciation done through pipe in homedir, handler daemon confuses startup/shutdown tools in unix, running multiple versions of mono under the same user causes deadlock in all mono processes)
architechture problems (x86 has usually worked. x86-64 has had various problems, powerpc has had some problems even with mint)
development prioritzation problems (in some situations, mono leaked memory like a seive. this was basically not considered to be severe problem for some time)
incompleteness problems (we have encountered a variety of.net framework incompletenesses where code which works on.net does not work on mono. Some of these issues have been known and documented, others clearly not started on yet, some inexplicably not working despite clearly being implemented in the mono framework source)
tool support issues (various issues have come up with nant and nunit, standard C# tools, not working well in various mono configurations)
Most of these issues have been either relatively minor or addresed as they have come up. Some are much more worrying (like the IPC deadlock problem which seem to stil afflict SVN head). The project seems to be generating solid code, but I would not really recomend it for production use unless you can budget 1-5% of your development time addressing mono-specific issues.
However, I have _much_ more serious criticisms of the C# language and.Net framework bedrock on which Mono is based.
C# is a relatively low productivity language like Java or C++. Some may not see this as a serious problem, but if you do not absolutely need the execution speed of this kind of environment, then I would recommend avoiding it and using something like Python or Ruby. The productivity gains really are huge.
The documentation is poor. MSDN is large and relatively complete, but the text frequently is worded sufficiently ambiguously that I have to write test code to see what it does, and hope I'm intuiting the corner cases correctly. Additionally, because the datatypes have poor facilities for representing themselves, I end up having to create special datastructure-to-string code for many of these tests. In python the docs are generally concise and unambiguous, and a test takes seconds. In C++ or C, writing tests is slow, but the available documentation is generally good enough that they are not required.
The language and framework assume you are using something like VisualStudio. Very often doing simple operations unambiguously will require over 80 characters of text to call a function. Names like System.IO.Path.GetDirectoryName as compared to python's os.path.dirname, and C's dirname.
The.Net framework in many places bleeds the Win32 API semantics right on through. When attempting to start another process, you create a process object with a single Filename and a single Arguments string. An execve equivalent to actually specify the arguments without having to wonder how the spaces will be handled is not available. The DirWatcher class defaults to viewing files specified by the expression "*.*" in the specification, but the specification does not specify how to interperet this string. File globbing operates differently on Unix implementaitons get to choose from implementing windows file globbing in a library, using unix globbing but not defaulting to finding all files in the directory (only those which contain a dot), or can refuse to follow the standard and default to "*". All of these choices have problems. There are other examples..Net is basically win32 in many many ways.
I could go on.
I do not recommend.Net/C# for cross platform development.
If you are writing a windows app, it will probably be less painful in.Net with C# than in C++ with raw win32 or with MFC etc. Personally I would try to use python with wxwidgets, but I don't have any experience so that could be bad advice.
Well sure, except the applications which don't store everything cleanly, which is a goodly percentage.
And of course the pain of having to install the applications again, by hand, feeding in CD after CD.
Don't forget lots of windows apps like to sprinkle paths here and there, so if you want everything to work as it was you'll have to install them to the same paths that you wrote down on a little post-it note.
Note: edit access to wikis is not really a problem. The only attack form that really matters is targetted robot attacks for example from spammers. These are generally blocked by subnet range exclusion, and are nothing but another form of DOS eventually, like pingflooding.
If someone edits your wiki and puts text on it, you can just go back to the last version or any other earlier version if you don't like their changes.
Proprietary means something is the property of someone. You believe that everything is property, but in reality this is of course a mental construct that people apply to the world. People can choose a vareity of mental constructs to apply to the world. Code in the public domain is not proprietary by the mental construct that is our legal system.
BSD licensed code and GPL code is to some extent similar to code in the public domain, and thus it is reasonable and rational to talk about it as not being proprietary.
That you cannot grasp this means you have failed to grasp the definition of proprietary, despite all your words.
Slashdot Mirror
Get real. You've fallen for the Slashdot propaganda.
No, I paraphrased the "slashdot propaganda". But it's not just slashdot's propaganda, these stories have appeared on other websites, newspaers, etc.
Again, this is not my view, but it is factual that these stories were broadly dissemenated.
Also, I don't give two hoots if slashdot was biased. Someone raised an issue as if they were pointing out hypocracy, when it's really quite consistent simple human behavior.
It's quite simple. People like to dump on the no-good-shits of the world. They like them clearly delineated and then they like to dump on them.
This allows them to feel better because they are part of a group, and clearly better than the target.
The RIAA with their sue-grandma stories sure look like they're really a bunch of jerks. So people dump on them. These people who appropriated a bunch of work that wasn't theirs are obviously a bunch of greedy bastards, so we dump on them too!
It's really not about the relative worth of the PearPC folks or the RIAA targets, but the clear-cut moral inadequacy of the party we get to therefore despise.
But you said you needed distributed key signing in order to make authentication work in the distributed model.
Is autopackage distributed? I thought it was.
Well, no, you are.
jrodman@Skonnos:~ >dpkg --status sudo
Package: sudo
Status: ok not-installed
Sudo is not a necessary component of unix.
apbuild only seems to cover libc issues, not issues with other libraries. Do you plan to cover all library interface changes?
For example, my distribution (debian) contains package names like libpng12, indicating that this particular package has gone through a total of 12 binary-incompatable interfaces changes. libpth is at version 14, and libcrypto++, for example, is apparently binary-incompatable with every release.
Other distributions do not even bother to rename for binary incompatabilities consistently.
How are these issues addressed?
Sane defaults are important.
/usr, you trade away short term pain for long term brokenness.
Providing bad defaults and allowing people to override them in a system which purports to be a usability substrate is bad planning.
Do not default to
Well, no.
Normally, my package maintainer gets the code from Trustworthy Tim by hand, inspects it by hand, cryptographically signs it by hand, and uploads it him/herself to the package repository where it is centrally managed without access from Evil Edward.
Autopackage provides a way for me to automate the setup and install, right? or wrong? If the autopackage automates dependencies, then it's an attack vector for spyware. If it doesn't automate dependencies, then it doesn't meet the described criteria for helping users.
But why would I want to use such an inferior implementation of vi. ;-)
Small is wm2.
At 63724 bytes, it's less than a third of the binary size of mwm that you quote, and it doesn't link against any huge bloated and unpleasant motif library. In fact, it only uses libXext, and X11 on top of the usual stdc++, libm, libgcc, libc, libdl and ld-linux. in-memory size can be as little as 10k malloced on top of the 60k image.
Yes, I used to live there, although I was more in the 1230X wheras 1234 was down near Guilderland.
Since I don't live giving fake information that actually reflects my own past, I usuaully use 10001 which is somewhere in manhattan.
To an extent, these are both problems. But I put much heavier criticism on any such MUA for having the ability to change and not doing so.
So do you have a workable key signing system in place which is proven in the field?
So tell me then.
How does autopackage allow me to authenticate that the provider of the autopackage is in fact the upstream software author Trustworthy Tim, and not Evil Patrick the Spyware Maven?
In case this isn't clear enough, assume that the upstream author Trustworthy Tim has never heard of or considered using autopackage.
Maybe I'm being too hardline her, but it sounds like you've added a misfeature to autopackage to complement the misfeature in the distribution.
/usr/local and then help distributions to support that, by default or as part of installing autopackage.
Default to
Every time autopackage gets mentioned, I look into it, only to come away lost as to what problem the project is trying to solve.
It claims to provide binary packages which will install on any distribution, but I don't see any sort of information about how the project plans to address the fact that binary interfaces on linux systems are moderately unstable. It just seems quixotic.
jrodman@Skonnos:~ >sudo rm -rf /
:~(
bash: sudo: command not found
Your virus doesn't work.
My guess:
More or less, writing viruses is legal, but writing viruses and releasing them is illegal.
Just writing it might be illegal in a court if they could convince a jury you intended to release it. That might be tricky since there is a history of people writing such things for nonrelease, and a subset that got out accidentally.
It spends a lot of time discussing what really happens in various situations and asserting that some theories that have been promoted are maybe incorrect, but does no investigative research.
Moreover, all these performance claims are bandied about, and yet I see no benchmarking.
Try harder, windows folks.
I have building an application in mono which shall remain nameless over the last six months.
I've encountered troubling issues in the following areas:
Most of these issues have been either relatively minor or addresed as they have come up. Some are much more worrying (like the IPC deadlock problem which seem to stil afflict SVN head). The project seems to be generating solid code, but I would not really recomend it for production use unless you can budget 1-5% of your development time addressing mono-specific issues.
However, I have _much_ more serious criticisms of the C# language and .Net framework bedrock on which Mono is based.
- C# is a relatively low productivity language like Java or C++. Some may not see this as a serious problem, but if you do not absolutely need the execution speed of this kind of environment, then I would recommend avoiding it and using something like Python or Ruby. The productivity gains really are huge.
- The documentation is poor. MSDN is large and relatively complete, but the text frequently is worded sufficiently ambiguously that I have to write test code to see what it does, and hope I'm intuiting the corner cases correctly. Additionally, because the datatypes have poor facilities for representing themselves, I end up having to create special datastructure-to-string code for many of these tests. In python the docs are generally concise and unambiguous, and a test takes seconds. In C++ or C, writing tests is slow, but the available documentation is generally good enough that they are not required.
- The language and framework assume you are using something like VisualStudio. Very often doing simple operations unambiguously will require over 80 characters of text to call a function. Names like System.IO.Path.GetDirectoryName as compared to python's os.path.dirname, and C's dirname.
- The
.Net framework in many places bleeds the Win32 API semantics right on through. When attempting to start another process, you create a process object with a single Filename and a single Arguments string. An execve equivalent to actually specify the arguments without having to wonder how the spaces will be handled is not available. The DirWatcher class defaults to viewing files specified by the expression "*.*" in the specification, but the specification does not specify how to interperet this string. File globbing operates differently on Unix implementaitons get to choose from implementing windows file globbing in a library, using unix globbing but not defaulting to finding all files in the directory (only those which contain a dot), or can refuse to follow the standard and default to "*". All of these choices have problems. There are other examples. .Net is basically win32 in many many ways.
I could go on. I do not recommendI'm actually interested in what you're saying, but you aren't trying hard enough to make your post comprehensible.
What are these acronyms?
Well sure, except the applications which don't store everything cleanly, which is a goodly percentage.
And of course the pain of having to install the applications again, by hand, feeding in CD after CD.
Don't forget lots of windows apps like to sprinkle paths here and there, so if you want everything to work as it was you'll have to install them to the same paths that you wrote down on a little post-it note.
And no, I'm really _not_ making this up.
OH HORROR!
You'll be able to put.. TEXT... on his wiki!
Note: edit access to wikis is not really a problem. The only attack form that really matters is targetted robot attacks for example from spammers. These are generally blocked by subnet range exclusion, and are nothing but another form of DOS eventually, like pingflooding.
If someone edits your wiki and puts text on it, you can just go back to the last version or any other earlier version if you don't like their changes.
Yes, there are SCSI CD burners and whatnot also. BIG INSIGHT.
Proprietary means something is the property of someone. You believe that everything is property, but in reality this is of course a mental construct that people apply to the world. People can choose a vareity of mental constructs to apply to the world. Code in the public domain is not proprietary by the mental construct that is our legal system.
BSD licensed code and GPL code is to some extent similar to code in the public domain, and thus it is reasonable and rational to talk about it as not being proprietary.
That you cannot grasp this means you have failed to grasp the definition of proprietary, despite all your words.
Atheists are not religious.