I'm very happy that their business model has failed.
The internet was there before these guys showed up and it will be there long after.
I'm eagerly awaiting the day that the stock market cleans out these dot-failures and makes sure they go dot-bust; and, en passant, delivers us from their "business models".
When your company asks IBM to develop code for them, your company will have to sign away all the rights to the resulting sources. Most likely, they'll only get binaries anyway.
When you develop sources for your company, it's the other way around.
No matter how hard you try to rationalize this, there is only one possible explanation: IBM is better at negotiating and in a stronger position than you are.
I personally never sign NDAs. Why ? Because I always manage to get contracts without them. And if the customer insists on an NDA, I usually say ok then, but it will be at a different rate altogether.
Even if MICROS~1 infringes on the GPL, what damages or lost sales could you claim? Therefore, we need to find a way to claim large, monetary damages for GPL violations.
That's why GPL authors shouldn't be afraid to license exemptions on the GPL, to companies that want the source code, want to distribute derivative works, but don't want to publish their modifications.
These exemptions should be charged for, heftily.
A violation of the GPL now involves a sizeable damage in dollar terms; because the infringing company should have paid the exemption fees!
Hence, you can sue for multiple damages (notwithstanding criminal charges) with the assistance of the best (money-smelling) lawyers of the world.
Going to court is not really an option, nor for me, neither for most people I know: I'm not going to pay those exorbitant lawyer fees.
It all boils down to: RULE 1="the one who can afford the lawyers will win." I don't agree with such rules.
Fortunately, such kind of rules don't apply indiscriminately in cyberspace. It's rather: RULE2="the one who can make your servers crash and burn will win."
So, I'm counting on cybermobs and hackers to bring down anyone who wants to play by RULE1 by enforcing RULE2.
We can't count on the legal system to defend our rights. Only the second amendment can.
The packaging service has been charged for and constitutes an economic transaction.
If www.cheapbytes.com charges $3.99 for sending you RH7.0 they have activated the taxation framework that will tax you on the $3.99 of the invoice total value.
Note that cheapbytes or any other vendor will(!) charge you something for packaging and retailing the product, even if that amount is rather nominal.
The tax level must be applied to $3.99 and not in reference to another software product that looks similar.
If the taxation is not computed on the $3.99 invoice total and is not applying the standard rate for that particular product class and country of origin, you should ask the taxing authority to review their decision.
If they fail to review their decision, you may consider litigating, in which case you will most certainly win, as this decision violates numerous treaties, including the ones covering WTO agreements, and local laws that implement these treaties.
Unfortunately, it will cost you well in excess of $3.99 to ensure that the law will be applied.
If you import millions of copies, this kind of issues will most certainly be resolved to your fullest satisfaction; most likely, with the assistance of the State Department. In all other cases you're f*cked.
Python is quite an ok language, even though I understand that quite a lot of developers are less than fond of the concept of "significant whitespace".
If you start off with the idea that one "significant" tab is equivalent to 4 "significant" spaces, things can turn out differently than you may have thought when the emacs setting of the day happens to be: 1 tab is traded for 5 significant spaces.
The real issues to me, however, are:
(1) Oosterhout says that the inner loops are to be coded in C, while the outer, administrative loops can be done in -Script-. I could have agreed with this idea, as it sounds good, if it were not that integrating C and -Script- becomes a project in itself. I dare you to figure out tools like SWIG, or even to use the python.h files manually. You're in there for some major undertaking. God save the queen!
(2) Now that you're finished SWIGging and re-SWIGging, compiling, re-compiling your libs, scripts, glue code, you can create your deployment package: an atrocious bunch of dlls,.py,.pyc,.pyd, dot anything files, and as a bonus, you will probably be forced to pollute the \system32 folder extensively with global dll-hell-raising dependencies. A python deployment is the definition itself of "system pollution". The McMillan installer is a conceptual heavyweight, gathering complex dependency trees; and watch it go wrong regardless: not really your mother's deployment tool.
(3) Python depends on a virtual machine, say the pyxxyy.dll, which shares the problems of all shared objects. While Guido was going from v1.52 to v1.6b to v1.6 to v2.0b to v2.0, which is fine, because that improves the system, it had one major drawback: continuous redeployment of almost identical but slightly different virtual machines. You will find that your virtual machine gets updated more rapidly than the applications that depend on it. What's more, virtual machines create a horrendous need for backward compatibility of the APIs, with its trail of deprecated classes, methods, and entire packages. All the cruft will remain there forever, and you will be deploying an everincreasing pile of mostly unneeded dog shit to your users. In my opinion, *virtual machining* is bound to end in tears.
I'm looking for a high-level language, regardless of its syntax that:
(1) understands seemlessly C/C++ header files and the APIs that it exposes. No SWIGgin! (But also, no IDL or stuff like that, just direct invocation!)
(2) grabs its language run-time (virtual machine) (whichever version that you indicate), native methods (.obj files), and your application, uncrufts it (removes every class or method not used) and nicely links it into one, single clean executable (optionally compressed with, for example, UPX).
No shared objects, no \system32 pollution, no dlls, no folders full of.pyd,.py,.pyc,.dll files! Just one.exe!
I don't understand the problem that some people have with these GUIs. They are just one way to publish the underlying APIs (for clicking). Just as the command line instruction is just another way to publish underlying APIs (for scripting).
The issue is that neither should be the only way in which a particular API is published. I resent as much the fact that an API is completely hidden behind a GUI (often the case in Windows) as an API that is completeley hidden behind a command line instruction (often the case in Unix/Linux).
For example, how can you use the Linux grep functionality in your code, without resorting to executing its commandline? Where are the APIs?
The security problem is an OS-level problem. The OS enables the admin to give permissions per user/sysobject and that is insufficiently granular in world with ubiquitous network connections and applications.
A user should also be able to reduce his own permissions when he doesn't trust a particular executable.
Example:
The admin gives user "Jacky" a particular set of permissions. If I am user "Jacky" and I want to execute an executable from source "www.donttrust.com", I should be able to set permissions for "Jacky-www.donttrust.com" that are a subset of the "Jacky" permissions and hence further reduce the potential havoc that source "www.donttrust.com" could create.
So, the internet has created a need for 2-level sysadminning. The sysadmin gives the user a subset of root, and the user gives a particular application source a subset of his own rights.
You could conceivably create a workaround, by creating new users, but in a normal context an ordinary user does not have the permission to create new users, nor should he have this permission.
In fact, this is a general OS problem to raise with the kernel and filesystem people.
His whitepaper is indeed a bit advanced on new ideas; I would definitely not mind, however, to see what places he will manage to visit using his subversive approach.
I don't mind companies like Tivo trying to control consumers' behaviour remotely and surreptitiously collect information from them.
However, nothing gives them the *right* to do so. If you manage to circumvent their BS, bad luck for them.
Now, some people will invoke the DMCA against circumvention.
This is exactly this kind of situations that are meant in the 2nd amendment and where we are encouraged to have the resolve to confront the MPAA, the RCAA and their corrupt puppets in Congress;
and to clarify that there is no need to abide by the law that was bought and paid for;
but instead, that we should recover the institutions of government for the people by the people;
by all means.
I'm ready to burn the Bastille in yet another Boston tea party!
Slashdot Mirror
I'm very happy that their business model has failed.
The internet was there before these guys showed up and it will be there long after.
I'm eagerly awaiting the day that the stock market cleans out these dot-failures and makes sure they go dot-bust; and, en passant, delivers us from their "business models".
And good so.
I'm really happy that so many people stand united and don't run closed-source software.
NO CLOSED SOURCE ON LINUX.
IF YOU WANT CLOSED-SOURCE, USE WINDOWS.
When are these thickhead morons going to understand that?
Have you ever wondered about the following?
When your company asks IBM to develop code for them, your company will have to sign away all the rights to the resulting sources. Most likely, they'll only get binaries anyway.
When you develop sources for your company, it's the other way around.
No matter how hard you try to rationalize this, there is only one possible explanation: IBM is better at negotiating and in a stronger position than you are.
I personally never sign NDAs. Why ? Because I always manage to get contracts without them. And if the customer insists on an NDA, I usually say ok then, but it will be at a different rate altogether.
Sorry. Life is hard.
Even if MICROS~1 infringes on the GPL, what damages or lost sales could you claim? Therefore, we need to find a way to claim large, monetary damages for GPL violations.
That's why GPL authors shouldn't be afraid to license exemptions on the GPL, to companies that want the source code, want to distribute derivative works, but don't want to publish their modifications.
These exemptions should be charged for, heftily.
A violation of the GPL now involves a sizeable damage in dollar terms; because the infringing company should have paid the exemption fees!
Hence, you can sue for multiple damages (notwithstanding criminal charges) with the assistance of the best (money-smelling) lawyers of the world.
And finally set an example!
Going to court is not really an option, nor for me, neither for most people I know: I'm not going to pay those exorbitant lawyer fees.
It all boils down to: RULE 1="the one who can afford the lawyers will win." I don't agree with such rules.
Fortunately, such kind of rules don't apply indiscriminately in cyberspace. It's rather: RULE2="the one who can make your servers crash and burn will win."
So, I'm counting on cybermobs and hackers to bring down anyone who wants to play by RULE1 by enforcing RULE2.
We can't count on the legal system to defend our rights. Only the second amendment can.
The packaging service has been charged for and constitutes an economic transaction.
If www.cheapbytes.com charges $3.99 for sending you RH7.0 they have activated the taxation framework that will tax you on the $3.99 of the invoice total value.
Note that cheapbytes or any other vendor will(!) charge you something for packaging and retailing the product, even if that amount is rather nominal.
The tax level must be applied to $3.99 and not in reference to another software product that looks similar.
If the taxation is not computed on the $3.99 invoice total and is not applying the standard rate for that particular product class and country of origin, you should ask the taxing authority to review their decision.
If they fail to review their decision, you may consider litigating, in which case you will most certainly win, as this decision violates numerous treaties, including the ones covering WTO agreements, and local laws that implement these treaties.
Unfortunately, it will cost you well in excess of $3.99 to ensure that the law will be applied.
If you import millions of copies, this kind of issues will most certainly be resolved to your fullest satisfaction; most likely, with the assistance of the State Department. In all other cases you're f*cked.
Python is quite an ok language, even though I understand that quite a lot of developers are less than fond of the concept of "significant whitespace".
.py, .pyc, .pyd, dot anything files, and as a bonus, you will probably be forced to pollute the \system32 folder extensively with global dll-hell-raising dependencies. A python deployment is the definition itself of "system pollution". The McMillan installer is a conceptual heavyweight, gathering complex dependency trees; and watch it go wrong regardless: not really your mother's deployment tool.
.pyd, .py, .pyc, .dll files! Just one .exe!
If you start off with the idea that one "significant" tab is equivalent to 4 "significant" spaces, things can turn out differently than you may have thought when the emacs setting of the day happens to be: 1 tab is traded for 5 significant spaces.
The real issues to me, however, are:
(1) Oosterhout says that the inner loops are to be coded in C, while the outer, administrative loops can be done in -Script-. I could have agreed with this idea, as it sounds good, if it were not that integrating C and -Script- becomes a project in itself. I dare you to figure out tools like SWIG, or even to use the python.h files manually. You're in there for some major undertaking. God save the queen!
(2) Now that you're finished SWIGging and re-SWIGging, compiling, re-compiling your libs, scripts, glue code, you can create your deployment package: an atrocious bunch of dlls,
(3) Python depends on a virtual machine, say the pyxxyy.dll, which shares the problems of all shared objects. While Guido was going from v1.52 to v1.6b to v1.6 to v2.0b to v2.0, which is fine, because that improves the system, it had one major drawback: continuous redeployment of almost identical but slightly different virtual machines. You will find that your virtual machine gets updated more rapidly than the applications that depend on it. What's more, virtual machines create a horrendous need for backward compatibility of the APIs, with its trail of deprecated classes, methods, and entire packages. All the cruft will remain there forever, and you will be deploying an everincreasing pile of mostly unneeded dog shit to your users. In my opinion, *virtual machining* is bound to end in tears.
I'm looking for a high-level language, regardless of its syntax that:
(1) understands seemlessly C/C++ header files and the APIs that it exposes. No SWIGgin! (But also, no IDL or stuff like that, just direct invocation!)
(2) grabs its language run-time (virtual machine) (whichever version that you indicate), native methods (.obj files), and your application, uncrufts it (removes every class or method not used) and nicely links it into one, single clean executable (optionally compressed with, for example, UPX).
No shared objects, no \system32 pollution, no dlls, no folders full of
I don't understand the problem that some people have with these GUIs. They are just one way to publish the underlying APIs (for clicking). Just as the command line instruction is just another way to publish underlying APIs (for scripting).
The issue is that neither should be the only way in which a particular API is published. I resent as much the fact that an API is completely hidden behind a GUI (often the case in Windows) as an API that is completeley hidden behind a command line instruction (often the case in Unix/Linux).
For example, how can you use the Linux grep functionality in your code, without resorting to executing its commandline? Where are the APIs?
The security problem is an OS-level problem. The OS enables the admin to give permissions per user/sysobject and that is insufficiently granular in world with ubiquitous network connections and applications.
A user should also be able to reduce his own permissions when he doesn't trust a particular executable.
Example:
The admin gives user "Jacky" a particular set of permissions. If I am user "Jacky" and I want to execute an executable from source "www.donttrust.com", I should be able to set permissions for "Jacky-www.donttrust.com" that are a subset of the "Jacky" permissions and hence further reduce the potential havoc that source "www.donttrust.com" could create.
So, the internet has created a need for 2-level sysadminning. The sysadmin gives the user a subset of root, and the user gives a particular application source a subset of his own rights.
You could conceivably create a workaround, by creating new users, but in a normal context an ordinary user does not have the permission to create new users, nor should he have this permission.
In fact, this is a general OS problem to raise with the kernel and filesystem people.
It is totally unrelated to the Java *language*.
His whitepaper is indeed a bit advanced on new ideas; I would definitely not mind, however, to see what places he will manage to visit using his subversive approach.
I don't mind companies like Tivo trying to control consumers' behaviour remotely and surreptitiously collect information from them.
However, nothing gives them the *right* to do so. If you manage to circumvent their BS, bad luck for them.
Now, some people will invoke the DMCA against circumvention.
This is exactly this kind of situations that are meant in the 2nd amendment and where we are encouraged to have the resolve to confront the MPAA, the RCAA and their corrupt puppets in Congress;
and to clarify that there is no need to abide by the law that was bought and paid for;
but instead, that we should recover the institutions of government for the people by the people;
by all means.
I'm ready to burn the Bastille in yet another Boston tea party!