There are some significant differences to RIP. For a start you require a court order, for which the investigator (say, the FBI) must produce prima facae evidence.
Second, I have seen no US law that requires the handing over of keys. There is a significant distinction, which (if the accept proposals) South Africa have hopefully got right: subject to a court order you can be forced to disclose the content of an encrypted communication (again, there is a requirement for prima facae evidence), but there is no requirement to hand of the keys.
I do agree, however, that the burden of proof part is somewhat worrying.
As much as I am anti-spam, there is an issue to be considered before banning spam outright: the exact definition.
Cold marketing is an accepted technique for generating interest and ultimately sales. Even though unsolicited faxes are not permitted in many parts of the world, cold marketing related material usually bypasses this restriction. Yet the distinction is a hair's bredth.
In most niche markets mass advertising is not cost effective. Cold marketing is often the most effective resort for business in such markets. I have over time had several unsolicited e-mails that I do not consider to be spam, but rather cold marketing. Why? Because they are targetted.
Should cold marketting be banned in an effort to ban spam? Or should the definition of spam be tightened up to refer not just to unsolicited marketting, but unsolocited and not relevant to the person/organisation.
Strictly speaking this is not correct. Gee, I've heard the line before;) Licensing is analogous to letting or renting, not to a sale subject to limited rights. At least, it is in terms of software and most other duplicatable intellectual property.
In the same way as you cannot sell a flat that you are letting, you cannot sell software that you are letting. In both cases you are bound to terms of agreement for the rental.
This is the model that software has informally followed; MS's latest licensing attempts move to the letting route far more clearly.
OTOH there are requirements for letting that place an onus on the owner; another aspect which has not been tested in court. If a flat is defective, it is the owner's responsibility to fix the problem in an acceptable manner and in a reasonable timeframe. By extension, software should be subject to the same requirements: bugs will HAVE to receive attention.
One final nasty: if a flat is in such poor condition that the letter or his/her property is damaged, the owner can be held liable. How many billions of Dollars of damage did Codered, SirCam and Nimda (apparently) cause?
Or, as is more obvious in South Africa, the government has made it more difficult to own or acquire personal firearms, which means that the hijacker with the illegal personal firearm has no resistance.
In my experience, the company's reputation does not suffer. I speak mainly of web development shops in this matter, but all to often there is oversell by the salesdroids, and there is no reasonable (sometimes even technilogically feasable) was to meet the targets.
But the company has this nice fineprint in the contract: "Quote is an estimate only; billing for actual hours worked will apply", or something to that effect. Basically everything is cool until the deadline, then the client starts jumping up and down demanding their software, which they get 100% late for twice the bill.
They bitch, moan and complain, but still come back to the company because of lock-in; not contractually, but because everyone else they talk to admits that to modify (update, maintain) the application will be difficult and costly for them without the original company's knowledge, design docs, etc (which, incidently, aren't part of the software and not purchased in the contract - bummer).
I know this goes for the UK and South Africa, and I'm sure there is at least some incidence of it in the US. "Churn it out fast 'n ugly, 'cause then they will pay more to maintain it" is the general rule. One day companies will catch on to this extortion, but they aren't at the point yet.
I know a number of damn good programmers who are simply not allowed to produce good code, because the company feels it is a waste of time. Sadly, the companys where they have produced good code have gone under in the dotcom slump... why? Because they took longer to do the job, and (sometimes) quoted higher in the first place. The perception is that anyone who can quote can do the job properly, so you go with the lowest bidder or the most established.
Only 28?;) In South Africa you get 14 public holidays, plus a minimum (statutory) 20 days paid leave per year. Plus a fairly liberal sick leave policy on top of that, and companies are expected to be fair in the granting of compassionate leave and leave for religious reasons (albeit unpaid).
CVS has a number of flaws, yes, but I still use it in preferance to any other SCC I've tried. Unfortunately CVS development seems to be a bit stale, at least in terms of innovation. There are a couple of improvements that could really improve CVS a lot.
Things We'd Like To See(TM):
Atomic commits.
They can be useful, and lots of people go wild about them.
Hierarchical module naming / access.
For those who have used Visual Sourcesafe you'll understand - you don't have to check out a project; you can "root" your checkout at any point in the tree. You "projects" (modules) can also be classified in a hierarchy, instead of being a list in the modules file.
Linking files between modules.
Code reuse is important in many environments, and often a file needs to be reused across several projects, without being a completely separate library. Several SCCs can link files across projects, including VSS. While I'm sure you can fiddle the server (on Unix systems) with ln, there is no CVS-provided means (via the client) for linking files.
Renaming files.
This happens more often than people care to admit. Its easy on the server, but you can't do it from the client without deleting and adding, which means you lose the history (which is what SCC is all about).
Multiple CVS servers.
This is very pertinent to the use of CVSup (at least, it was last time I tried - haven't used distributed repositories in about a year). Although you can check out from a slave repository, you have to check in to the master. This means that you have to use -d on every checkin to specify the master. CVS needs a built-in mechanism to tell it where to check-out, and where to check-in.
Backup.
One of my pet peeves, since I have to work in a commercial environment. I need easy, reliable backup. With CVS, I have to write a script to do this for me, and consider the locking of directories, etc. Since I'm one of the few people in the company with Unix knowledge, this puts CVS on the "dangerous because of maintenance" list, and makes it unpopular.
Built-in transfer security.
CVS over SSH is nifty and solves the security problem, but its certainly not easy, especially to set up as a server, and especially if you are trying to run your server under NT! CVS needs a built-in secure transport layer (say, SSL) either as a default or as an option.
Just a small point, but LLC is a generic that includes ALL corporations, not just what the US refers to as an LLC (Close Corpoation to various other parts of the world). Public, private and other companies or corporations are all limited liability.
Second, US is fairly unique in allowing lawyers, accountants and doctors to practice under LLCs -- in most parts of the world these professions in particular are restricted to practicing in partnerships for a number of ethical and legal reasons.
Third, while a LLC is not a "get out of jail free" card, it is often employed as one. The mere fact that the people responsible for running the company aren't playing with their own money, and know that everyone has a limit to how much they can be held responsible for, leads to greater risk taking, often with disasterous consequences.
Refer to the dot bomb: you take excessive risk with other peoples' money, in the hope of excessive reward. In your wake you leave excessive debt, which is *wait for it* the creditor's problem -- not yours, and not the investors. So long as you did your fideciary duty and were not actually reckless in trading, the "corporate officers" aren't responsible either.
While the dot-com slump has left thousands of investors in the IT sector out of pocket, it has had equally serious (but often overlooked) consequences for other market sectors that have had to absorb the bad debts left by dot bombs.
The reason MS is looking good to win this one is simple: they're up again ICQ, AOL, Jabber, and a host of other "standards" that aren't.
MS is unable to usurp protocols that are global, standard and massively distributed. Think FTP, HTTP and SMTP. Instant messaging needs to lose the we-rely-on-a-single-server complex (don't bullshit me about Jabber and multiple servers - it doesn't get more distributed than IRC).
If you want to beat MS at instant messaging, pioneer benefits for users. 1: Use existing support in SMTP for IM, or extend SMTP to do IM better. OpenSource mail software runs over 50% of the 'net -- MS can't fight that. 2: Use e-mail addresses as IM addresses, not a new ID per network.
Relating that back to Passport & co: your e-mail address becomes your identity. If you can authenticate yourself to your home SMTP server (as you do to pick up POP mail, for example), then the SMTP server is "identified" by DNS, and able to vouch for the e-mail address user being consistent over time. Anonimity, privacy, and authentication (to some degree).
I own patent 1011/2389 "A system for registering innovations allowing a period of exclusity to the original registree, and prohibiting all others from using said innovation without paying obnoxious license fees to the registered owner of the innovation".
Your "patent" infringes on this patent, so you'll have to transfer all that $$$ plus some more to me:)
My understanding of the patent system is that patents are very specific. Having a patent for exercising a cat with a laser pointer does not mean you can sue someone for exercising their dog, budgie or cute furry martian in the same manner. Similarly (as you have noted) having patented "1-click shopping" does not give Amazon exclusive rights to "n-click shopping", despite apparent similarities.
Firstly: "Material object" has specific meaning under the law, which does not include non-physical (classically: intellectual) property. Material must, necessarily, be physical. Transferring information and then placing it on a disk and giving the disk to the purchaser would be covered by this patent.
The catch arises in that downloading to your hard drive would also constitute placing data on a disk, and since the point at which the purchase was made was your computer, it would constitute a point-of-sale. Arguably the mere act of such information entering RAM is "reproduction in a material object at the point of sale"; so depending on where you draw the line on "material object" (can it already belong to the purchaser, or must it be included in the sale?) and "point-of-sale" that clause can be read in several ways.
Secondly: As you kindly pointed out (all prior threads seem to miss this rather salilent point) this applies to a limited set of downloads, mostly commercial. Whenever an authorization is needed to initate the download or, conveivably, to interpret the downloaded information, the patent could take effect. In addition the use of "point of sale" as the description of the location strongly implies (but maybe not strongly enough for the courts) the requirement for a sale (negotiated trade or financial transaction) to occur.
So: browsing the web under normal conditions and downloading free software is not convered. Download evaluation software where a registration and key is needed may be covered.
Curve ball: web sites that require authentication and/or use SSL may be grey areas. Consider that under both systems the intended recipient of information must provide some form of authorization in response to a request for such authorization (in the case of SSL without client authentication, that "code" is randomly generated). The only missing part for you to stretch the patent over it (if you had good lawyers) would be the concept of sale. But how broad is sale?
Well, the commercial (capatalist, Western, etc) world holds that no-one does anything for free. The courts have shown a bias towards that view (I'm not bothering to explain the references/logic here). So if you have registered with a site as a user, it could be argued that, in exchange for your right to use the site (the authorization code you were given), you have agreed to a trade, mostly likely the site has permission to e-mail you and share your e-mail address with its partners. That's a sale. Worried yet?
Thirdly: the patent is specific about the method of authorization: the owner obtains a code, and supplies it in response to a prompt at the "point of sale". That's pretty broad -- sure, I believe we could make a protocol that avoided the problem (public keys and signatures, for example, in which case you prove identity rather than supply a code), but most site currently work on the prompt/authorization code principle.
As much as I hate to admit it, I think it is possible to stretch this patent to cover a large amount of the net. But certainly it cannot cover all downloads: free http (non-SSL) websites, free software, e-mail, search engines, usenet and the like cannot (except by an lawyer) possibly be perceived to fit under the umbrella of this bastard.
But there is the question: does the patent imply (strongly enough for the courts) that the material object constitutes part of the sale? If so, download to your hard drive is not covered.
How much time have you dedicated today to reading Slashdot... and how much to your vocation / studies / whatever? How much information have you absorbed (from any source) compared to how much you have used?
Its all very well becoming a pool of information, but that only helps trivia players. To be useful, information must be processed into knowledge, a transition which requires time and practice. To realise the usefulness of knowledge, it must be practiced in an rewarding manner. The reward may be of social, psychological or economic benefit (or others).
The "information overload" phenomena is becoming an increasing problem, especially for "techies". It is no longer an option to be a well-rounded guru - there is simply too much information to absorb, and not enough time for understanding or realisation.
These guys have hit the issue bang on the nose. In a race to keep up with information, you cannot realise the benefits that are supposed to come from keeping up.
The psychology of the problem is closely related to Attention Defecit Disorder. This is often cited as a "learning disability" and is common in "underachievers", but those are dangerous terms: an "underachiever" is anyone not meeting their estimated potential, and can be a straight-A student (I know several such cases). ADD is aggrevated in bright kids by lack of stimulus; ADD is aggrevated in other kids when they are unable to keep up with the pace of learning, and cannot comprehend the new information.
"Other kids" grow into "other adults", and make up the bulk of the population. Continual assualt with new information renders them unable to keep up - yet they know that in order to succeed in their careers they are expected to. A host of social problems result, not the least of which is attention disoders.
Ever screamed in frustration because you've been trying to wrap your mind around something for an hour, and can't? That's not attention - its attention defecit, unless you're really incapable of understanding the concept.
"Bright adults" can suffer from the same problem if they are experiencing pressure to stay ahead of the curve.
The surest sign of information ADD is the greater tendency of information workers to abuse Internet privlidges at work. While most would hardly consider a whole host of other entertainment possibilities, they cannot resist the lure of the Internet, even though it can cost them their jobs. Unable to concentrate on their work, they "go surfing" and end up aggrevating the situation. How many days have you "got nothing done"?
Let's put it this way... I'm at^H^Havoiding work right now...
Shouldn't we be welcoming this "idea registration" idea? How many calls have we had in the past 6 months for a prior art / ideas registry to assist in fighting software patents?
On a more serious note, the officials in question fobbed off the problem by saying that the claim was false, as the claimant hadn't invented the wheel. But the point of a patent (or even registration of an idea) is to have some form of evidence that you DO have an original claim to the idea! Were the registration challanged, it falls back on your word that you were the innovator... basically, registration means nothing!
The VC and OpenSource relationship has always seemed terribly weird to me. Almost all win32 ports of GNU or other OpenSource tools I have used require VC to compile. I have tried to get some of them to compile under gcc/Cygwin with luck only with a few of those supporting automake, and then only with modifications (though I haven't tried must in the last year).
The support for mingw/32 seems worse, since it doesn't have the Unix emulation layer provided by Cygwin... but at least you don't need the Cygwin DLL!
It strikes me that there are a number of free compilers / environments out there for win32, not the least of which being gcc or Borland's C++.
Given this support, and Borland's apparent intent to support the OpenSource community with community licensing for Kylix, why are ported STILL supporting VC (especially knowing that few people have legal access to it?).
The GNOME team has been trying to bring some form of component model to Linux. Last time I looked (which was just under a year ago) I didn't like what I saw.
While they praised themselves on having a better idea than M$, their model (of Bonobo) was based EXACTLY on COM, with the basic interfaces being identical.
I have tried several times to engage Linux/*nix developers in conversations over component models, and they seem to "not get it". A similar problem to trying to convince this same group 5 years ago that C++ and OOP were good ideas.
We can just hope that in 5 years time they will come around. Unfortunately it is in matters like this that the community needs to be proactive in developing new standards.
Refer to the XML-RPC/SOAP developments: XML-RPC predates SOAP, but is Really Sucky (TM). Its true RPC, with no support for objects. SOAP itself is sucky - its bloated and underpowered - yet more and more effort is being put into supporting SOAP in opensource (especially the Java opensource developments), and not enough into innovation.
We have learned painfully over YEARS how to develop good protocols that are lightweight, fast (both in transfer time and processing time) and extensible. Neither SOAP nor XML-RPC fit the bill ; a couple of M$ (and associated) FUDmeisters have got even the OpenSource folks onboard with the idea that "human-readable protocols are the way to go".
I think the concept of unfairness stems from a distinction between "receiving money" and "receiving benefits". Millions of people stand to benefit from the growth of OpenSource and the availability of free software. Millions of people stand to benefit from Microsoft making more profits, not the least of whom are shareholders and end-users who should be getting new technologies in return for their cash.
In amongst the flames, legalese and politicking, there is a very basic concept underlying both arguments: payment. MS demands payment in cash, GPL demands payment in kind. MS demands payment for all forms of use, GPL demands payment only when the software is modified.
MS is in the business of selling software to end users as well as developers, so the GPL has a direct financial effect on their business. Hence their attack on the GPL, hence a response targetted at MS in particular.
While advocates of free software (and I mean free speech as well as free beer, as advocated by the FSF) may like to see no-one making money from commercial software, most people appreciate the fact that the software industry is economically important, and can produce many things that free software won't (not necessarily can't).
Oracle have never attempted to redden the GPL (think communism if you're missing the implication), or ban the use of OpenSource tools in conjunction with their software. And after a certain now-infamous backdoor was discovered in another leading product after its source was opened, there were several calls to all te major RDBMS vendors to provide access to their source code.
Craig Mundie has, before the world's media, expressed Microsoft's official view on free software. Now he is being asked to substantiate that view with hard facts, instead of making frivilous claims. I hardly think that's unfair.
First, the inability to distinguish a relationship between applications and DLLs, because not all applications correctly add this information to the registry.
Second, the tendency of the system or applications to "break" because a DLL upon which they depend has changed.
In the second case, refer to the problem of the glibc upgrades. All applications had to be recompiled. Not a massive problem in a world where everything is distributed as source code, but when it came to binaries (and the Windows platform is completely binary based), it was a big issue. Unix has the same problems as Windows, we just don't see them as often because the core libraries are more stable.
If you don't install DLLs in the system directory, and they are shared DLLs, then you lose the benefit of software reuse. You end up with dozens of copies of the same DLL.
I think the author of this article is failing to make an important distinction between tool chains and software components.
Unix unquestionably derives enormous power from tool chains, as described by the article. But a tool chain, or part of a tool chain, is not a component.
You COULD sort your database using sort, but you don't. You COULD select records using grep, but you don't. You COULD use a perl one-liner to total accounts in your general ledger, but you don't. The reason is that these routines need to be integrated into a software application, to prevent the mess of utilities that plague legacy applications.
The answer is components. These are not discrete tools; they cannot exist alone. A component is only meaningful when integrated into a larger application.
The author would have done a lot better to draw attention to the wealth of shared libraries available on Unix, yet even these are a poor approximatation of a reusable component model, despite their obvious value.
There are many good reasons to use COM, not the least of which being that COM offers geniunely reusable object oriented components. COM is, unfortunately, a good vision but a poor implementation. Still, it is somewhat better than DLLs (MS's equivalent of shared libraries).
The "perfect solution" is somewhere out there, not that we'll ever find it. But a step in the right direction would be a compromise between shared libraries and COM (read: shared object libraries), with effective yet simple bindings in a multitude of languages.
Why isn't the usual/. paranoia kicking in yet? Although the article says that the device "is not for everyone", imagine the potential for abuse! 'Sir, your kid is showing signs of depression: he's being bullied and wearing black. We'd like to put him on a NeuroGizmo 5000 before we end up with another Columbine'.
Depression is, in general, not a bad thing. It is a defense and/or coping mechanism, and to develop as an individual, and be able to function properly in society, most people need to overcome depression without assistance. Psychiatrists are often reluctant to prescribe drugs mostly because of potential side-effects, including dependancy. But when there are no side effects...
For all the good they can do, little things like this need to be watched, or we may have it made law that everyone carry one to force us into utopian society...
Stonehenge is a rather different problem to the pyramids.
For a start, the source of the stones used in Stonehenge is known, and it is from several hundred miles away (Southern Wales IIRC). This means that the biggest "wow" in the building of Stonehenge was the transport of the stones, and not erecting them.
Stonehenge is a group of discrete, freestanding stones, with the exception of the cross-pieces. Moving a stone into an upright position is a relatively simple exercise, even if it involves lots of gym. Upright timbers and ropes would have been more than sufficient, when combined with manpower, to lift the stones.
Placing the crosspieces, too, is more simple than the problems faced by the pyramids. For starters you only have to elevate the stone three meters. Given the amount of timber available in Britain (as opposed to the massive amount you will find lying all over in Egypt...), it would not be difficult to build a strong enough scaffold. The Stonehenge crosspieces are also signifcantly smaller than the blocks used to build the pyramids.
It should be noted that Stonehenge is the largest and most well known of the ancient British monuments, but not the only one. There are several similar, but smaller, examples within a few miles of Stonehenge itself, and may others scattered around the countryside.
The pyramids were larger (on a massive scale), the stones used were larger (in general), and the structure consisted of many more than two layers of stone. In Egypt it is assumed the ramps were made of sand and mud, rather than timber, but significant amounts of timber would still be required as uprights either for scaffolding or simply to get leverage to raise (turn over, turn upright) blocks.
Of course, you're assuming the egyptology argument in stating that the Pharoahs built the pyramids.
Ignoring the precession argument (which is interesting but hardly scientific proof) there is a wealth of geological evidence that the pyramids are a lot older than the Egyptian civilization. The erosion patterns on the Sphinx alone are enough to rebut most "accepted" theories about ancient Egypt.
The hieroglyphics found so far do not contain a wealth of information on the building of the pyramids. They strongly imply the presence of slave labour and the use of slaves in matters regarding the pyramids, but this could indicate maintenance or conversion into a tomb, rather than building (from scratch).
Of course, if the pyramids do predate Egyptian civilization, there will be no record of ramps or kites or another other building method to explain them, in hieroglyphics...
Socially the "Egyptians had a lot of slaves" theory is a little hard to swallow.
Mathematics proves that even a significant advantage over enemies in combat will be nullified if the enemy has overwhealming numbers. Simply put, if your army can kill two of the enemy for every one you lose, the enemy does not need to be anywhere near twice your number to win.
Even if mathematics was not at the forefront of slave minds, it is (and has been throughout human conquests) seemingly obvious to the minds of the repressed that sheer numbers and will can overcome a stronger foe.
So work the numbers a little. If the slaves were so weak compared to the Egyptians, they would hardly be capable of lifting obelisks. Ropes and pullys can only "scale" so far before throwing more bodies at the problem does not improve the chances of solving it. Space also allows a limited number of people to occupy it at once. Besides which, lifting stones builds muscle. Basically, the slaves were not weaklings.
If the slaves were so numerous, whether weak or strong, they would have an advantage of numbers over the Egyptians. Even with weapons, a limited number of Egyptians would be no match for an angry slave mob.
We have no reason to believe that the Egyptians had any knowledge of slave repression the surpasses what we know today. All in all, there is no way that Egyptian society could have been stable if it had so many slaves.
The ideal debug/log system should take a single line to invoke, and not have additional overheads.
No, this is not the ideal. You are oversimplifying the truth. In large projects, it is desirable to keep logging abstracted from the problem at hand...
And using a single line to invoke a log statement prevents this how? debug(facility, message);
Quite simple, have multiple levels (the method call), facilities, etc.
Maybe I wasn't clear enough, and/or my words have been misunderstood. A certain amount of overhead to set up logging configuration is acceptable. Log statements should be a single line, with no overhead (say having to create/obtain a category object).
Log4J, for all its "complexity", lacks the ability to specify, from a central configuration point, a filter to determine what statements go where. Log4J's filtering is based on categories and nested diagnostic contexts, both of which are hard-coded into the software.
From a single-line debug statement (which includes a facility) it is an easy matter to filter based on any knowledge available: source file, class, method, thread, facility, priority, message content. It would become a matter of altering the configuration file to have "all FATAL messages from thread XYZ containing the word Wombat get logged to this.file".
Oh yes, that situation is n complexity, if you don't count the configuration overhead (1 line: Debug.loadConfig(file); ). In this situation Log4J is n+1 complexity, plus the use of NDCs are requiried. That adds a push and pop at times, so the complexity ranges from n+1 to n+4.
With regards to speed,
I never mentioned speed; it is not an issue in my development.
With regards to size, the core library is 78K. The complete library (core + utility classes that you can mix and match to your needs) is 159K.... Is this going to make or break your hard drive capacity or is this simply an aesthetic gripe?
Hard drive capacity is obviously not a concern. Download size is a concern. Add 159k for the 8 new APIs introduced in the latest JDK version, and you have an extra 1.28Mb of libraries. And extra 1.28Mb that pushes Java more over the "reasonable download" limit.
A lot of people in the US (I'm assuming you are) don't realise how poor bandwidth is in some area of the world. I'm in a "moderate" bandwidth area - 56k dialup is common, ISDN is starting to make an appearance, and medium companies have dedicated 64k or 128k sync lines. Convincing someone to download an 8.8Mb file is not easy.
So are you complaining that people want to reuse code or that they don't want to waste time reinventing the wheel (two sides of the same coin)?
I have three complaints:
1. Sun is stifling growth and development of third-party components. Although I no longer directly depend on this for income, I know many people and organisations that do. One of Java's strengths is the suitability to component development.
Few people need all the APIs that are included in the JRE. Most software I have need to distribute does not require JDBC or Swing, for example. This is true of a huge amount of Java software. The JRE should be a runtime core, not an all-encompassing library.
I appreciate the need for code reuse, and the Java libraries are the single main reason I prefer the platform; but there is a point at which it becomes overkill. Distribute a core JRE, and have downloadable "extension" libraries, that software distributors can list are required for the functioning of their product.
3. (and most important) By adding the API to Java, Sun makes it a standard. Developers are keen to take advantage of standards, and the capabilities provided, so they will use them in preference to third-party components or APIs, even if the alternatives are superior. This is exactly the problem Log4J is facing: it is a better solution to the problem than Sun's intended solution, yet the inclusion of JSR47 will mean that most Java development will now use the Sun standard API. In other words, an API should NOT be included in the JRE core unless it is either fundamental to the modelling of the language, or is accepted as a de facto standard and the best known solution to the problem.
And finally, your C++ anecdote is somewhat misleading. I think you're taking for granted that the standard C and C++ libraries are installed by default on many systems.
Erm...no. The applications in question were compiled with Borland C++ Builder, and those libraries aren't standard on 'doze. The distribution was statically linked, completely. Once packages into a compressed self-executable install bundle, it was 673kb. A similar (but not fully functional) Java program to perform the same function was 112kb in a JAR, and required the JRE (with Swing, of course).
If you don't like Java, then don't use it.
On the contrary, I like Java. I have been using it since 1995. I would like to use Java exclusively, and am trying to convince managers and customers that it is a better solution. Unfortunately Sun's handling of certain issues, like the continual inclusion of new APIs -- especially when they're not necessary the best or accepted standards -- complicates the issue.
As a result I have had to resort to using the right tool for the job... and for the jobs I have mentioned that tool was C++ (in fact, the project was specified as VB but the VB runtime is also too large to download, or to expect the customer to have...).
You can take a small, highly powerful jackhammer into a mine to rescue trapped workers... but its useless unless you can get the 1 ton pneumatic generator close enough to connect the hose...
Slashdot Mirror
There are some significant differences to RIP. For a start you require a court order, for which the investigator (say, the FBI) must produce prima facae evidence.
Second, I have seen no US law that requires the handing over of keys. There is a significant distinction, which (if the accept proposals) South Africa have hopefully got right: subject to a court order you can be forced to disclose the content of an encrypted communication (again, there is a requirement for prima facae evidence), but there is no requirement to hand of the keys.
I do agree, however, that the burden of proof part is somewhat worrying.
As much as I am anti-spam, there is an issue to be considered before banning spam outright: the exact definition.
Cold marketing is an accepted technique for generating interest and ultimately sales. Even though unsolicited faxes are not permitted in many parts of the world, cold marketing related material usually bypasses this restriction. Yet the distinction is a hair's bredth.
In most niche markets mass advertising is not cost effective. Cold marketing is often the most effective resort for business in such markets. I have over time had several unsolicited e-mails that I do not consider to be spam, but rather cold marketing. Why? Because they are targetted.
Should cold marketting be banned in an effort to ban spam? Or should the definition of spam be tightened up to refer not just to unsolicited marketting, but unsolocited and not relevant to the person/organisation.
Strictly speaking this is not correct. Gee, I've heard the line before ;) Licensing is analogous to letting or renting, not to a sale subject to limited rights. At least, it is in terms of software and most other duplicatable intellectual property.
In the same way as you cannot sell a flat that you are letting, you cannot sell software that you are letting. In both cases you are bound to terms of agreement for the rental.
This is the model that software has informally followed; MS's latest licensing attempts move to the letting route far more clearly.
OTOH there are requirements for letting that place an onus on the owner; another aspect which has not been tested in court. If a flat is defective, it is the owner's responsibility to fix the problem in an acceptable manner and in a reasonable timeframe. By extension, software should be subject to the same requirements: bugs will HAVE to receive attention.
One final nasty: if a flat is in such poor condition that the letter or his/her property is damaged, the owner can be held liable. How many billions of Dollars of damage did Codered, SirCam and Nimda (apparently) cause?
But when they discover that the legitimate business-person sells pot, they have a lovely paper trail right to your doorstep.
The most important aspect of cash in modern society is anonymity.
Or, as is more obvious in South Africa, the government has made it more difficult to own or acquire personal firearms, which means that the hijacker with the illegal personal firearm has no resistance.
In my experience, the company's reputation does not suffer. I speak mainly of web development shops in this matter, but all to often there is oversell by the salesdroids, and there is no reasonable (sometimes even technilogically feasable) was to meet the targets.
But the company has this nice fineprint in the contract: "Quote is an estimate only; billing for actual hours worked will apply", or something to that effect. Basically everything is cool until the deadline, then the client starts jumping up and down demanding their software, which they get 100% late for twice the bill.
They bitch, moan and complain, but still come back to the company because of lock-in; not contractually, but because everyone else they talk to admits that to modify (update, maintain) the application will be difficult and costly for them without the original company's knowledge, design docs, etc (which, incidently, aren't part of the software and not purchased in the contract - bummer).
I know this goes for the UK and South Africa, and I'm sure there is at least some incidence of it in the US. "Churn it out fast 'n ugly, 'cause then they will pay more to maintain it" is the general rule. One day companies will catch on to this extortion, but they aren't at the point yet.
I know a number of damn good programmers who are simply not allowed to produce good code, because the company feels it is a waste of time. Sadly, the companys where they have produced good code have gone under in the dotcom slump ... why? Because they took longer to do the job, and (sometimes) quoted higher in the first place. The perception is that anyone who can quote can do the job properly, so you go with the lowest bidder or the most established.
/end_rant.
Only 28? ;) In South Africa you get 14 public holidays, plus a minimum (statutory) 20 days paid leave per year. Plus a fairly liberal sick leave policy on top of that, and companies are expected to be fair in the granting of compassionate leave and leave for religious reasons (albeit unpaid).
CVS has a number of flaws, yes, but I still use it in preferance to any other SCC I've tried. Unfortunately CVS development seems to be a bit stale, at least in terms of innovation. There are a couple of improvements that could really improve CVS a lot.
Things We'd Like To See(TM):
They can be useful, and lots of people go wild about them.
For those who have used Visual Sourcesafe you'll understand - you don't have to check out a project; you can "root" your checkout at any point in the tree. You "projects" (modules) can also be classified in a hierarchy, instead of being a list in the modules file.
Code reuse is important in many environments, and often a file needs to be reused across several projects, without being a completely separate library. Several SCCs can link files across projects, including VSS. While I'm sure you can fiddle the server (on Unix systems) with ln, there is no CVS-provided means (via the client) for linking files.
This happens more often than people care to admit. Its easy on the server, but you can't do it from the client without deleting and adding, which means you lose the history (which is what SCC is all about).
This is very pertinent to the use of CVSup (at least, it was last time I tried - haven't used distributed repositories in about a year). Although you can check out from a slave repository, you have to check in to the master. This means that you have to use -d on every checkin to specify the master. CVS needs a built-in mechanism to tell it where to check-out, and where to check-in.
One of my pet peeves, since I have to work in a commercial environment. I need easy, reliable backup. With CVS, I have to write a script to do this for me, and consider the locking of directories, etc. Since I'm one of the few people in the company with Unix knowledge, this puts CVS on the "dangerous because of maintenance" list, and makes it unpopular.
CVS over SSH is nifty and solves the security problem, but its certainly not easy, especially to set up as a server, and especially if you are trying to run your server under NT! CVS needs a built-in secure transport layer (say, SSL) either as a default or as an option.
Well, thats my 2c.
Just a small point, but LLC is a generic that includes ALL corporations, not just what the US refers to as an LLC (Close Corpoation to various other parts of the world). Public, private and other companies or corporations are all limited liability.
Second, US is fairly unique in allowing lawyers, accountants and doctors to practice under LLCs -- in most parts of the world these professions in particular are restricted to practicing in partnerships for a number of ethical and legal reasons.
Third, while a LLC is not a "get out of jail free" card, it is often employed as one. The mere fact that the people responsible for running the company aren't playing with their own money, and know that everyone has a limit to how much they can be held responsible for, leads to greater risk taking, often with disasterous consequences.
Refer to the dot bomb: you take excessive risk with other peoples' money, in the hope of excessive reward. In your wake you leave excessive debt, which is *wait for it* the creditor's problem -- not yours, and not the investors. So long as you did your fideciary duty and were not actually reckless in trading, the "corporate officers" aren't responsible either.
While the dot-com slump has left thousands of investors in the IT sector out of pocket, it has had equally serious (but often overlooked) consequences for other market sectors that have had to absorb the bad debts left by dot bombs.
The reason MS is looking good to win this one is simple: they're up again ICQ, AOL, Jabber, and a host of other "standards" that aren't.
MS is unable to usurp protocols that are global, standard and massively distributed. Think FTP, HTTP and SMTP. Instant messaging needs to lose the we-rely-on-a-single-server complex (don't bullshit me about Jabber and multiple servers - it doesn't get more distributed than IRC).
If you want to beat MS at instant messaging, pioneer benefits for users. 1: Use existing support in SMTP for IM, or extend SMTP to do IM better. OpenSource mail software runs over 50% of the 'net -- MS can't fight that. 2: Use e-mail addresses as IM addresses, not a new ID per network.
Relating that back to Passport & co: your e-mail address becomes your identity. If you can authenticate yourself to your home SMTP server (as you do to pick up POP mail, for example), then the SMTP server is "identified" by DNS, and able to vouch for the e-mail address user being consistent over time. Anonimity, privacy, and authentication (to some degree).
Sorry, you can't do that.
I own patent 1011/2389 "A system for registering innovations allowing a period of exclusity to the original registree, and prohibiting all others from using said innovation without paying obnoxious license fees to the registered owner of the innovation".
Your "patent" infringes on this patent, so you'll have to transfer all that $$$ plus some more to me :)
#include "std_IANAL.h"
My understanding of the patent system is that patents are very specific. Having a patent for exercising a cat with a laser pointer does not mean you can sue someone for exercising their dog, budgie or cute furry martian in the same manner. Similarly (as you have noted) having patented "1-click shopping" does not give Amazon exclusive rights to "n-click shopping", despite apparent similarities.
Firstly: "Material object" has specific meaning under the law, which does not include non-physical (classically: intellectual) property. Material must, necessarily, be physical. Transferring information and then placing it on a disk and giving the disk to the purchaser would be covered by this patent.
The catch arises in that downloading to your hard drive would also constitute placing data on a disk, and since the point at which the purchase was made was your computer, it would constitute a point-of-sale. Arguably the mere act of such information entering RAM is "reproduction in a material object at the point of sale"; so depending on where you draw the line on "material object" (can it already belong to the purchaser, or must it be included in the sale?) and "point-of-sale" that clause can be read in several ways.
Secondly: As you kindly pointed out (all prior threads seem to miss this rather salilent point) this applies to a limited set of downloads, mostly commercial. Whenever an authorization is needed to initate the download or, conveivably, to interpret the downloaded information, the patent could take effect. In addition the use of "point of sale" as the description of the location strongly implies (but maybe not strongly enough for the courts) the requirement for a sale (negotiated trade or financial transaction) to occur.
So: browsing the web under normal conditions and downloading free software is not convered. Download evaluation software where a registration and key is needed may be covered.
Curve ball: web sites that require authentication and/or use SSL may be grey areas. Consider that under both systems the intended recipient of information must provide some form of authorization in response to a request for such authorization (in the case of SSL without client authentication, that "code" is randomly generated). The only missing part for you to stretch the patent over it (if you had good lawyers) would be the concept of sale. But how broad is sale?
Well, the commercial (capatalist, Western, etc) world holds that no-one does anything for free. The courts have shown a bias towards that view (I'm not bothering to explain the references/logic here). So if you have registered with a site as a user, it could be argued that, in exchange for your right to use the site (the authorization code you were given), you have agreed to a trade, mostly likely the site has permission to e-mail you and share your e-mail address with its partners. That's a sale. Worried yet?
Thirdly: the patent is specific about the method of authorization: the owner obtains a code, and supplies it in response to a prompt at the "point of sale". That's pretty broad -- sure, I believe we could make a protocol that avoided the problem (public keys and signatures, for example, in which case you prove identity rather than supply a code), but most site currently work on the prompt/authorization code principle.
As much as I hate to admit it, I think it is possible to stretch this patent to cover a large amount of the net. But certainly it cannot cover all downloads: free http (non-SSL) websites, free software, e-mail, search engines, usenet and the like cannot (except by an lawyer) possibly be perceived to fit under the umbrella of this bastard.
But there is the question: does the patent imply (strongly enough for the courts) that the material object constitutes part of the sale? If so, download to your hard drive is not covered.
How much time have you dedicated today to reading Slashdot ... and how much to your vocation / studies / whatever? How much information have you absorbed (from any source) compared to how much you have used?
Its all very well becoming a pool of information, but that only helps trivia players. To be useful, information must be processed into knowledge, a transition which requires time and practice. To realise the usefulness of knowledge, it must be practiced in an rewarding manner. The reward may be of social, psychological or economic benefit (or others).
The "information overload" phenomena is becoming an increasing problem, especially for "techies". It is no longer an option to be a well-rounded guru - there is simply too much information to absorb, and not enough time for understanding or realisation.
These guys have hit the issue bang on the nose. In a race to keep up with information, you cannot realise the benefits that are supposed to come from keeping up.
The psychology of the problem is closely related to Attention Defecit Disorder. This is often cited as a "learning disability" and is common in "underachievers", but those are dangerous terms: an "underachiever" is anyone not meeting their estimated potential, and can be a straight-A student (I know several such cases). ADD is aggrevated in bright kids by lack of stimulus; ADD is aggrevated in other kids when they are unable to keep up with the pace of learning, and cannot comprehend the new information.
"Other kids" grow into "other adults", and make up the bulk of the population. Continual assualt with new information renders them unable to keep up - yet they know that in order to succeed in their careers they are expected to. A host of social problems result, not the least of which is attention disoders.
Ever screamed in frustration because you've been trying to wrap your mind around something for an hour, and can't? That's not attention - its attention defecit, unless you're really incapable of understanding the concept.
"Bright adults" can suffer from the same problem if they are experiencing pressure to stay ahead of the curve.
The surest sign of information ADD is the greater tendency of information workers to abuse Internet privlidges at work. While most would hardly consider a whole host of other entertainment possibilities, they cannot resist the lure of the Internet, even though it can cost them their jobs. Unable to concentrate on their work, they "go surfing" and end up aggrevating the situation. How many days have you "got nothing done"?
Let's put it this way ... I'm at^H^Havoiding work right now ...
Shouldn't we be welcoming this "idea registration" idea? How many calls have we had in the past 6 months for a prior art / ideas registry to assist in fighting software patents?
On a more serious note, the officials in question fobbed off the problem by saying that the claim was false, as the claimant hadn't invented the wheel. But the point of a patent (or even registration of an idea) is to have some form of evidence that you DO have an original claim to the idea! Were the registration challanged, it falls back on your word that you were the innovator ... basically, registration means nothing!
The VC and OpenSource relationship has always seemed terribly weird to me. Almost all win32 ports of GNU or other OpenSource tools I have used require VC to compile. I have tried to get some of them to compile under gcc/Cygwin with luck only with a few of those supporting automake, and then only with modifications (though I haven't tried must in the last year).
The support for mingw/32 seems worse, since it doesn't have the Unix emulation layer provided by Cygwin ... but at least you don't need the Cygwin DLL!
It strikes me that there are a number of free compilers / environments out there for win32, not the least of which being gcc or Borland's C++.
Given this support, and Borland's apparent intent to support the OpenSource community with community licensing for Kylix, why are ported STILL supporting VC (especially knowing that few people have legal access to it?).
The GNOME team has been trying to bring some form of component model to Linux. Last time I looked (which was just under a year ago) I didn't like what I saw.
While they praised themselves on having a better idea than M$, their model (of Bonobo) was based EXACTLY on COM, with the basic interfaces being identical.
I have tried several times to engage Linux/*nix developers in conversations over component models, and they seem to "not get it". A similar problem to trying to convince this same group 5 years ago that C++ and OOP were good ideas.
We can just hope that in 5 years time they will come around. Unfortunately it is in matters like this that the community needs to be proactive in developing new standards.
Refer to the XML-RPC/SOAP developments: XML-RPC predates SOAP, but is Really Sucky (TM). Its true RPC, with no support for objects. SOAP itself is sucky - its bloated and underpowered - yet more and more effort is being put into supporting SOAP in opensource (especially the Java opensource developments), and not enough into innovation.
We have learned painfully over YEARS how to develop good protocols that are lightweight, fast (both in transfer time and processing time) and extensible. Neither SOAP nor XML-RPC fit the bill ; a couple of M$ (and associated) FUDmeisters have got even the OpenSource folks onboard with the idea that "human-readable protocols are the way to go".
Roses, noses ... you know the rest.
I think the concept of unfairness stems from a distinction between "receiving money" and "receiving benefits". Millions of people stand to benefit from the growth of OpenSource and the availability of free software. Millions of people stand to benefit from Microsoft making more profits, not the least of whom are shareholders and end-users who should be getting new technologies in return for their cash.
In amongst the flames, legalese and politicking, there is a very basic concept underlying both arguments: payment. MS demands payment in cash, GPL demands payment in kind. MS demands payment for all forms of use, GPL demands payment only when the software is modified.
MS is in the business of selling software to end users as well as developers, so the GPL has a direct financial effect on their business. Hence their attack on the GPL, hence a response targetted at MS in particular.
While advocates of free software (and I mean free speech as well as free beer, as advocated by the FSF) may like to see no-one making money from commercial software, most people appreciate the fact that the software industry is economically important, and can produce many things that free software won't (not necessarily can't).
Oracle have never attempted to redden the GPL (think communism if you're missing the implication), or ban the use of OpenSource tools in conjunction with their software. And after a certain now-infamous backdoor was discovered in another leading product after its source was opened, there were several calls to all te major RDBMS vendors to provide access to their source code.
Craig Mundie has, before the world's media, expressed Microsoft's official view on free software. Now he is being asked to substantiate that view with hard facts, instead of making frivilous claims. I hardly think that's unfair.
There are two aspects to "DLL Hell":
First, the inability to distinguish a relationship between applications and DLLs, because not all applications correctly add this information to the registry.
Second, the tendency of the system or applications to "break" because a DLL upon which they depend has changed.
In the second case, refer to the problem of the glibc upgrades. All applications had to be recompiled. Not a massive problem in a world where everything is distributed as source code, but when it came to binaries (and the Windows platform is completely binary based), it was a big issue. Unix has the same problems as Windows, we just don't see them as often because the core libraries are more stable.
If you don't install DLLs in the system directory, and they are shared DLLs, then you lose the benefit of software reuse. You end up with dozens of copies of the same DLL.
I think the author of this article is failing to make an important distinction between tool chains and software components.
Unix unquestionably derives enormous power from tool chains, as described by the article. But a tool chain, or part of a tool chain, is not a component.
You COULD sort your database using sort, but you don't. You COULD select records using grep, but you don't. You COULD use a perl one-liner to total accounts in your general ledger, but you don't. The reason is that these routines need to be integrated into a software application, to prevent the mess of utilities that plague legacy applications.
The answer is components. These are not discrete tools; they cannot exist alone. A component is only meaningful when integrated into a larger application.
The author would have done a lot better to draw attention to the wealth of shared libraries available on Unix, yet even these are a poor approximatation of a reusable component model, despite their obvious value.
There are many good reasons to use COM, not the least of which being that COM offers geniunely reusable object oriented components. COM is, unfortunately, a good vision but a poor implementation. Still, it is somewhat better than DLLs (MS's equivalent of shared libraries).
The "perfect solution" is somewhere out there, not that we'll ever find it. But a step in the right direction would be a compromise between shared libraries and COM (read: shared object libraries), with effective yet simple bindings in a multitude of languages.
Why isn't the usual /. paranoia kicking in yet? Although the article says that the device "is not for everyone", imagine the potential for abuse! 'Sir, your kid is showing signs of depression: he's being bullied and wearing black. We'd like to put him on a NeuroGizmo 5000 before we end up with another Columbine'.
Depression is, in general, not a bad thing. It is a defense and/or coping mechanism, and to develop as an individual, and be able to function properly in society, most people need to overcome depression without assistance. Psychiatrists are often reluctant to prescribe drugs mostly because of potential side-effects, including dependancy. But when there are no side effects ...
For all the good they can do, little things like this need to be watched, or we may have it made law that everyone carry one to force us into utopian society...
Stonehenge is a rather different problem to the pyramids.
For a start, the source of the stones used in Stonehenge is known, and it is from several hundred miles away (Southern Wales IIRC). This means that the biggest "wow" in the building of Stonehenge was the transport of the stones, and not erecting them.
Stonehenge is a group of discrete, freestanding stones, with the exception of the cross-pieces. Moving a stone into an upright position is a relatively simple exercise, even if it involves lots of gym. Upright timbers and ropes would have been more than sufficient, when combined with manpower, to lift the stones.
Placing the crosspieces, too, is more simple than the problems faced by the pyramids. For starters you only have to elevate the stone three meters. Given the amount of timber available in Britain (as opposed to the massive amount you will find lying all over in Egypt ...), it would not be difficult to build a strong enough scaffold. The Stonehenge crosspieces are also signifcantly smaller than the blocks used to build the pyramids.
It should be noted that Stonehenge is the largest and most well known of the ancient British monuments, but not the only one. There are several similar, but smaller, examples within a few miles of Stonehenge itself, and may others scattered around the countryside.
The pyramids were larger (on a massive scale), the stones used were larger (in general), and the structure consisted of many more than two layers of stone. In Egypt it is assumed the ramps were made of sand and mud, rather than timber, but significant amounts of timber would still be required as uprights either for scaffolding or simply to get leverage to raise (turn over, turn upright) blocks.
Of course, you're assuming the egyptology argument in stating that the Pharoahs built the pyramids.
Ignoring the precession argument (which is interesting but hardly scientific proof) there is a wealth of geological evidence that the pyramids are a lot older than the Egyptian civilization. The erosion patterns on the Sphinx alone are enough to rebut most "accepted" theories about ancient Egypt.
The hieroglyphics found so far do not contain a wealth of information on the building of the pyramids. They strongly imply the presence of slave labour and the use of slaves in matters regarding the pyramids, but this could indicate maintenance or conversion into a tomb, rather than building (from scratch).
Of course, if the pyramids do predate Egyptian civilization, there will be no record of ramps or kites or another other building method to explain them, in hieroglyphics ...
Socially the "Egyptians had a lot of slaves" theory is a little hard to swallow.
Mathematics proves that even a significant advantage over enemies in combat will be nullified if the enemy has overwhealming numbers. Simply put, if your army can kill two of the enemy for every one you lose, the enemy does not need to be anywhere near twice your number to win.
Even if mathematics was not at the forefront of slave minds, it is (and has been throughout human conquests) seemingly obvious to the minds of the repressed that sheer numbers and will can overcome a stronger foe.
So work the numbers a little. If the slaves were so weak compared to the Egyptians, they would hardly be capable of lifting obelisks. Ropes and pullys can only "scale" so far before throwing more bodies at the problem does not improve the chances of solving it. Space also allows a limited number of people to occupy it at once. Besides which, lifting stones builds muscle. Basically, the slaves were not weaklings.
If the slaves were so numerous, whether weak or strong, they would have an advantage of numbers over the Egyptians. Even with weapons, a limited number of Egyptians would be no match for an angry slave mob.
We have no reason to believe that the Egyptians had any knowledge of slave repression the surpasses what we know today. All in all, there is no way that Egyptian society could have been stable if it had so many slaves.
And using a single line to invoke a log statement prevents this how?
debug(facility, message); Quite simple, have multiple levels (the method call), facilities, etc.
Maybe I wasn't clear enough, and/or my words have been misunderstood. A certain amount of overhead to set up logging configuration is acceptable. Log statements should be a single line, with no overhead (say having to create/obtain a category object).
Log4J, for all its "complexity", lacks the ability to specify, from a central configuration point, a filter to determine what statements go where. Log4J's filtering is based on categories and nested diagnostic contexts, both of which are hard-coded into the software.
From a single-line debug statement (which includes a facility) it is an easy matter to filter based on any knowledge available: source file, class, method, thread, facility, priority, message content. It would become a matter of altering the configuration file to have "all FATAL messages from thread XYZ containing the word Wombat get logged to this.file".
Oh yes, that situation is n complexity, if you don't count the configuration overhead (1 line: Debug.loadConfig(file); ). In this situation Log4J is n+1 complexity, plus the use of NDCs are requiried. That adds a push and pop at times, so the complexity ranges from n+1 to n+4.
I never mentioned speed; it is not an issue in my development.
Hard drive capacity is obviously not a concern. Download size is a concern. Add 159k for the 8 new APIs introduced in the latest JDK version, and you have an extra 1.28Mb of libraries. And extra 1.28Mb that pushes Java more over the "reasonable download" limit.
A lot of people in the US (I'm assuming you are) don't realise how poor bandwidth is in some area of the world. I'm in a "moderate" bandwidth area - 56k dialup is common, ISDN is starting to make an appearance, and medium companies have dedicated 64k or 128k sync lines. Convincing someone to download an 8.8Mb file is not easy.
I have three complaints:
1. Sun is stifling growth and development of third-party components. Although I no longer directly depend on this for income, I know many people and organisations that do. One of Java's strengths is the suitability to component development.
Few people need all the APIs that are included in the JRE. Most software I have need to distribute does not require JDBC or Swing, for example. This is true of a huge amount of Java software. The JRE should be a runtime core, not an all-encompassing library.
I appreciate the need for code reuse, and the Java libraries are the single main reason I prefer the platform; but there is a point at which it becomes overkill. Distribute a core JRE, and have downloadable "extension" libraries, that software distributors can list are required for the functioning of their product.
3. (and most important) By adding the API to Java, Sun makes it a standard. Developers are keen to take advantage of standards, and the capabilities provided, so they will use them in preference to third-party components or APIs, even if the alternatives are superior. This is exactly the problem Log4J is facing: it is a better solution to the problem than Sun's intended solution, yet the inclusion of JSR47 will mean that most Java development will now use the Sun standard API. In other words, an API should NOT be included in the JRE core unless it is either fundamental to the modelling of the language, or is accepted as a de facto standard and the best known solution to the problem.
Erm...no. The applications in question were compiled with Borland C++ Builder, and those libraries aren't standard on 'doze. The distribution was statically linked, completely. Once packages into a compressed self-executable install bundle, it was 673kb. A similar (but not fully functional) Java program to perform the same function was 112kb in a JAR, and required the JRE (with Swing, of course).
On the contrary, I like Java. I have been using it since 1995. I would like to use Java exclusively, and am trying to convince managers and customers that it is a better solution. Unfortunately Sun's handling of certain issues, like the continual inclusion of new APIs -- especially when they're not necessary the best or accepted standards -- complicates the issue.
As a result I have had to resort to using the right tool for the job ... and for the jobs I have mentioned that tool was C++ (in fact, the project was specified as VB but the VB runtime is also too large to download, or to expect the customer to have...).
You can take a small, highly powerful jackhammer into a mine to rescue trapped workers ... but its useless unless you can get the 1 ton pneumatic generator close enough to connect the hose ...