I'm hardly surprised. How can you understand functions and procedures without understanding the conceptual model of a functional program? How can you understand pointers, references and pass-by-value without understanding the execution model behind the program?
To teach, you have to start at the beginning. Programming is the means, which comes in just before the end. The approach of teaching students how to hack their way along in a visual language is a primary cause of the number of inept developers, and gives our profession a bad name. Bookkeeping is a well-established profession: if you get a useless bookkeeper, you blame the person or the institution. A useless developer is assumed to be par for the course.
Programming courses need to start with the most basic topic: what IS a program. Then the theory of how programs run (jumping around to repeat bits of processing, and varying the processing with parameters). Followed by how we achieve that using source code and a compiler.
Only then can a student appreciate and understand what they are going to be doing when they "program".
You are discussing the difference between maths, engineering and social science. Programming can unfortunately only be described as a social science subject.
In maths you are presented with the result (the theory), and then with the proof. You don't need to satisfy yourself that it is correct emperically or "in the real world" or that its better to do it that way. Its proven.
In engineering you are presented with the result. You don't care about the proof, because you know that there is research and proof underlying the result, and you use the result in the recommended way to achieve those ends.
In social science everyone has their own theory. Some people rise to the top of the pile, and get continually picked on. Occasionally someone provides sufficient emperical evidence to justify the result being called a fact within the subject's domain.
This is the case with subjects like psychology and computer science. There is always more than one way to do or interpret something, and ego dictates that you must contest "accepted facts", and either derive or disprove the result for yourself.
Programming SHOULD be taught as an engineering subject. There is a body of knowledge for programming according to the conceptual model in use, and it is based on hard evidence from decades of development.
Unfortunately, software engineers prefer to make their own cement rather than ask the expert cement maker for the properties of the cement that is readily available.
Some friendly advise from the Been There Done That department:
You clearly don't have a fucking clue about business, or business users, or business purchasers, or business administrators. Cost makes up a 10% sway on the final choice. Period.
Were this not the fact, Microsoft would not get away with fleecing 90% of the world's business users of $800 every two years for an operating system, office suite, and server licenses.
Even when there is a clearly better and cheaper alternative from a technical viewpoint, it will often not be chosen. Business attaches a high value to a high price, and is prepared to pay the price.
The support model doesn't work either. Business expects to BUY, not to license. Hence the exodus from MS at the moment. Buying makes them confident that they're getting a decent product (even when they're not) - paying for support means they KNOW they're getting shit.
Precisely. Some RMS's long diatribes about "free speech and not free beer" being the intention of the GPL are actually bullshit. He has actively prevented (through the GPL) there being the possibility of free speech without free beer.
Finally RMS shows his true colours. The UnitedLinux companies have guaranteed gratis access to the source code, which means free speech is satisfied. But despite RMS's continual statements that "its okay to sell GNU software", when it comes down to it, he's going to throw a frothy is your are giving it awat, gratis.
So much for free speech. RMS cares more about beer.
Oh dear, another file format debate. I'm glad there was a library suggestion though... that allows us to change our mind when we do it wrong the first time;)
First, you need to consider the possibilitiy of moving the mailbox. To a different computer, or a different platform. This means it must be easy to access in any environment, and the tools must be portable.
This doesn't completely rule out a database solution (like mySQL), but it certainly makes it less-than-ideal.
Second, having used many mailers which separate out attachments... Please Don't Do It! You can't easily move your mailbox, because there are a host of associated attachment files. There is ALWAYS a synchronisation issue between attachments and messages, so you end up scanning and cleaning out the attachment folder every so often to prevent dead files from accumulating.
Compression is nifty, but isn't really important. Disk space is seldom a concern these days, and the really big stuff (binaries) is often already compressed or don't compress well.
The real issue with most mailbox formats is how do you deal with the problem of removing dead space from the mailbox? Some program just leave it there until you hit "compact", which is wasteful and confuses users. Others rewrite the entire mailbox every time, which causes the software to "hang" for a while on shutdown.
The best suggestion I can come up with off the top of my head is this: One file per mailbox folder, and that file is its own filesystem. The "root node" contains a group of summaries (from, to, subject, date, etc) and node links. Other nodes are chained to contain the message and attachments.
Handling attachments: attachments are separated out and stored as binary in the mailbox. This conserves space but keeps the attachment with the message.
Compacting: is avoided. When a mail is deleted, it is merely flagged in the root node (index). So each mailbox has its own deleted items folder, so to speak. When the deleted items folder is empties, the index is rewritten and nodes freed - every node not at the end of the file is overwritten with a node from the end of the file (and appropriate reindexing done), so the file is automatically compacted.
Ideally the file needs some sort of transation logging area to ensure its integrity at all times.
Shared access to files is best handled through a library or a service. File locking is notoriously prone to bugs and security issues, and avoiding multiple implementations in different mail clients would be beneficial.
I am fully versed in the FSF's philosophies. I just disagree with them. I do not find the GPL in the interests of "all computer users" because it has serious (negative) implications for creativity, standardization, and the sharing process.
RMS's rampant anti-Copyright arguments are fatally flawed in their assumption that software can exist in a form beneficial for all, without an economic model. RMS has also brainwashed people into accepting his explanation of "free speech" versus "free beer". The GPL enforces (not merely permits) "free speech", but also "free beer".
What this means for the man in the street is Bad News. Seeing a need, an industry can produce software to fulfil that need. In doing so it engages in economic activity, providing jobs to people like (surprise surprise) us. But if it must use the GPL, it can only be guaranteed a single sale. The first purchaser is permitted the rights to modify and redistribute the software, and resell it. No, not just it - but infinite copies, at any price (s)he choses. So it comes down to the fact that business cannot survive under an "only GPL" model.
On the flip side of the coin, let's assume that business is NOT involved. Free Software developers have got together and made a product. The end user STILL loses. Why? Because free software is notoriously shit compared to commercial alternatives when it comes to usability. It is typically made by geeks, for geeks. More specifically, the free software movement today is characterised by following. All of the features present in "productivity apps" (those which are of interest to normal home users) have debuted in commercial software, and the ideas simply copied.
All of this goes to say that the GPL stifles creativity. When there is no economic incentive, creativity declines.
Very few people benefit from the "freedom" offered by GPL software, unless we're talking "free beer". The vast majority of end users do not have the means to use the source code, and are confused and intimidated by the GPL. This reduces the sharing process. I am bound by severe legal constraints if I choose to give a copy of a GPL application to someone. I must include the source code (inconvenient, since I may not have chosen to obtain it), or provide an offer to provide the person with the source code. The GPL says it is NOT sufficient that I merely direct the recipient to the web site of the original source code (even if I haven't made any modifications), because as the distributor the onus is on ME to provide the source.
So much for easy sharing.
Which brings me to standardization, the central topic of my original post. Contrary to your belief, I don't want businesses to be treated as charities. I want meaningful contribution in both directions. And given the history of the situation, I don't believe this can be achieved using the GPL.
The FSF can treat itself as a sole light in the darkness of Copyright, fighting to bring a new age of Enlightenment to desktops near and far. And it can fail, because its efforts are continually divided by the (perceived) requirement to provide compatibility.
Or it can make reasonable efforts to reconcile its philosophy with that of the rest of the world, and work together nicely for a better future. And that means a give-and-take relationship with industry. "You can't have this unless you give us the commercial product its going to be a tiny part of" is not a give-and-take relationship.
The BSD license allows a business to benefit from free software. And it allows the business to contribute back in a manner it sees fit. A business almost certainly doesn't want to spend millions developing a commercial product, and then give it away for free (speech and/or beer), but it is likely to be willing to contribute extensions, fixes, and code that doesn't threaten its commercial model back into the free software space.
Or, to put it another way: if you don't give them anything, why the hell should they give something to you?
There are very few companies that can, or do, practice "embrace and extend". It only works effectively if you are a monopoly.
The LGPL does not make you use the LGPL as the license for your derivative work, but it has some say in what the license for your derivative work must allow
My point was very simply that the LGPL is itself a viral license: section 6 requires that a work linked to LGPL covered code be modifiable. It implies that object code (so that the work can be relinked against a modified version of the library) is sufficient, but this is unclear, as the section refers to two different things as constituting "a work".
At the very least, this means that if you use g++ to compile your C++ programs (which will then in all liklihood uses the facilities of libstdc++, which is covered by the LGPL) you must distribute the object files to allow relinked against a different version of libstdc++. At worst, it requires you to make your source code available to customers.
I agree with this position - business etiquette says go up the chain of command to get a message to someone in another department. Having said that, it can be useful to approach someone directly on an informal basis, assuming they are approachable.
In a breif and uncharacteristic defense of MCSEs (or MCNE), one entire non-elective module (out of 6 for an MCSE) is devoted to TCP/IP networking, from the ground up. The go over the OSI model extensively, and all of the TCP/IP theory. But they don't cover routing protocols (BGP, RIP, etc) in great detail, and they don't cover network security as a separate issue (i.e. you are trained to maintain and diagnose a network, and told to get an expert to deal with firewalls).
Ensuring freedom for who, exactly? When I develop software "for free", I want people to use it. The more people use common libraries, the less we are faced with a diversity of protocols and formats. That means commercial organisations too - FSF/OSS developers spend most of their time playing "compatibility catchup".
But most importantly, the GPL fails in its efforts to encourage code sharing, because it locks out the largest potential resource of high-quality, useful code: business.
Business can't use GPL code in its products, and is skeptical about LGPL (with good reason: see section 6 of the LGPL!). So it doesn't use (L)GPL code, doesn't contribute back (via testing, maintenance or extension), and neither side benefits. The only time businesses LIKE the GPL is when they release their own code, because it restricts competitors from using it.
BSD licenses OTOH allow everyone to share. Sure, some people abuse the situation. But the community loses nothing in real terms.
provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications
Frankly, this scares the shit out of me. It gives carte blanch for any intended user to modify the work, which implies (without saying so explicitly) the availability of source code.
Now put this in the context of using C++ compiled with GCC. The binary must be linked against libstdc++, which is LGPL.
Unless I'm going completely off the wall, this says that any C++ program compiled with GCC must have its source available to customers. Viral indeed!
Does someone want to tell me if I've lost the plot, and why?
OS/2 was a cooperative project between IBM and MS. IBM designed and wrote the low-level stuff, including the kernel, security system, object system, and object communication (OLE, DDE, etc). MS did the pretty stuff on top, all the while putting more work into Windows 3.0.
When Windows was ridiculously more successful than OS/2, MS licensed a huge amount of IBMs technology behind OS/2, defined a 32 bit API (which evolved slightly to become the Win32 API) and build NT. In the process they removed all of the crap that made OS/2 difficult to use. We know that crap better as "security features" and "robust object model".
(No, this is not a joke. MS intentionally removed a whole lot of security from IBM's code to create NT 3.1 and 3.51. Then it removed even more to create NT 4.0. The original design was sufficient for Orange book B1 classification.
This is bulshit which is only allowed to survive because no-one raises complaints against company directors for neglecting their fidiciary duty.
A company is a juristic person, and the directors are entrusted with making decisions on behalf of the company. Their behaviour is described fidiciary duty, and includes as two of its most important requirements the wellbeing of the COMPANY (not the shareholders) and that the company act in a manner consistent with the law (i.e. the directors are its morality and conscience).
A company which screws its support base in order to make money is NOT acting in its best interests. If such action is taken and doubt is cast by the market on the long-term viability of the company, then the directors may have failed in their fidiciary duty, and any shareholder can raise a complaint with the appropriate body.
Has anyone actually bothered to read these patents? I've browsed through half of the/. comments so far, and seen only patents vs. the GPL arguments. Where this any other company being discussed, they would have been shredded for patenting the patently obvious.
The first patent covers an HTTP server in kernel space which caches static and dynamic parts of pages separately. Yay. ASP (with caching on) and JSP do exactly this, but not in kernel space (at least, we're assuming ASP doesn't run in kernel space). So they're going to patent something because they were the first to think of putting it into the kernel (supposedly). What complete bullshit!
The second patent is even more ludicrous. Keep a cache of open files (name->handle map by implication) to improve performance - you don't have to open the file again if its already open. Heck, why didn't I think of that?! Ooops, I did. Used it several times.
RedHat has not invented anything. Its filing for bogus patents, probably as a defensive tactic. And as the GNU proponents have kindly pointed out, RedHat is fscked if it doesn't license the patents appropriate (to allow free software development) because they will then be violating the GPL by integrating TUX into the kernel. And if they don't do this then TUX won't be covered by their patent. Doh!
Maybe somebody needs to gather hard evidence of prior art an sumit it to the USPTO before they award this patent...?
This sort of high-profile case is just crying out for a shown of public support. Do you think a couple of free software heavyweights could agree on a middle-of-the-road viewpoint on Copyright law (by which I mean somewhere other than abolish it) in a form that "open IP" supporters everywhere (or just in the US;) ) could "sign" in an online show of support.
The recent/. article on Copyright would probably been a good place to look for ideas;)
Re:The concept of intellectual property has got to
on
Fair IP Laws?
·
· Score: 2
An excellent reply:) I feel it necessary to add my 2c though...
In both scenarios (refugee/goldrush) Copyright does not enter the picture. Copyright is not about restricting the free flow of information; it is about restricting the free copying of a particular incarnation of that information.
Fact #1: You can't copyright a fact. You can copyright the exact sequence of words you use to express a fact, but that doesn't prevent someone from reading that fact and telling someone else or writing it down in his/her own words.
Copyright as applied to facts encourages authors/publishers to put facts into words because they can receive remuneration for a collection of facts (a work). Without copyright on works of fact there would be no incentive to record facts, and we would rely on the facts recorded by a small number of altruists.
Fact #2: You can copyright a fiction. If you have made something up, it is not information. It is a fabrication. Here copyright is not restricting the free flow of information, but the reproduction of a creation.
Without copyright in this scenario, authors have no incentive to create, because their creation can be duplicated without them receiving anything (fame OR fortune).
You draw a distinction between "inside" and "outside" the company, as does the GPL (I agree). I do not know if US law permits this distinction, but SA law does not. A company is a separate, opaque, legal person. Employees cannot be "inside" a company for any legal purpose. They may have a contract with a company, but they are in no way part of the company, any more than you are part of your best friend (excluding spouses).
So you then have to decide how software works in this model. Is the company the owner, and allowing you to use the software it owns as a sort of service? Or does the company effectively transfer that license to you for the duration of your contract, since you are a separate legal entity to the company?
This presents an interesting legal challange in the case of commercial software too. If you have per user licensing of an MS operating system, for example, you have the right to install and use that OS on your home computer in addition to your work computer, providing you are the (sole/primary) user of both systems. Why? Because from the legal viewpoint the company transfers the right of license to you as part of your contract of employment.
In the GPL case, the company has the choice of providing software or service, and this may be a way around the catch-22 in our legal system. But the point nevertheless stands that this IS a legal minefield for the uninitiated.
It is an accepted wisdom that too much of anything is a bad thing; that includes too much freedom. RMS has too much rope, and is hanging free software in general.
Why do I make such sweeping claims? First, RMS is against proprietary software in any form. This is inherently self-defeating: the developers who work on free software can't do so for free. Industry has proven that the support model is nowhere near as effective as the software sale model, which means that the support model can't sustain enough developers to ensure the progression of software.
RMS's views have also shown themselves to be ineffective in stimulating innovation, something that should be rife in the free software community. Free software in general has been a technology follower for years, and its getting worse. Monitor the news on FSF/OSS sites and all you see is new projects which are trying to clone commercial products or architectures.
One of the reasons for this continual game of catch-up is that there is no scope for sharing of GNU source code with companies - in either direction. A company cannot license its code or binaries in a way that will allow it to persue the software sale model AND make RMS happy. So GNU developers must make their own version from scratch in order to achieve compatibility.
Conversely, companies are provided with no incentive to use GNU software in their products. At a push they may use software under the LGPL, but without such incentives to companies, they will not allocate corporate resources to activities which ultimately could (not necessarily would) improve the quality, functionality or quantity of free software. The worst part is that because companies don't reuse free software, but build their own, they have their own unique bugs and "features", which obviously cause imcompatibilities with other implementations... which they don't correct. So it comes back to the GNU developers to make further additions to their software to support the incompatibilities.
So basically not having a way to share between GNU software and commercial software bites free software in a number of ways.
In my dealings with pro-GNU people I've been astounded to found how some of them have their heads so far up their arses that they are completely unaware of the state of commercial software, the features available, etc. I still hear claims like "Windows sucks - it crashes 5 times a day" being made seriously. Sure, my Windows 2000 box has crashed 5 times in the last 3 months. This was due to power failures. And I lost nothing, unlike the Linux box which couldn't boot after the second crash. But I digress (somewhat)...
How can hardcode GNU/free software supporters make claims about software they have never used? Or should I rather ask: how can the Pope understand Hinduism?
But the most debilitating of RMS's activities is his persuit of trying to convince all free software developers to use the GNU license. Thanks to Microsoft's tactics and, in part, RMSs responses, industry is very skeptical about using GNU software. This makes it extremely difficult to broaden the scope of Linux usage.
Here is an extreme case: a company wants to rid itself of Windows, and rolls out Linux workstations to all of its employees. Catch 22: the employees have the right to the source code for Linux, since you are providing them with binaries for their use; but the employees by contract are only allowed to use the computers for approved activites, which does not require the availability or use of the Linux source code. This is not a silly construct, it is a serious legal opinion (not originating from myself).
Misunderstanding of the GPL is as rife as misunderstanding of the MS EULA. The presence of viral clauses is enough to make bean counters shit themselves without fully understanding the implications.
In general, RMS doesn't seem to understand that companies don't give a shit about the availability of source code. Corporate governance isn't about technically sound solutions, its about arse covering. Pay for a commercial product, and you can expect support (even if you have to pay). It may cost more, but when all hell breaks loose you can say "I did my homework, I paid for support, its their problem now". There is no "if" about hell breaking loose - you have to assume it WILL happen. And you need to be covered.
RMS encourages the support model for free software, but its not breaking into the market because GNU software can't keep pace with corporate resources.
Until the FSF learns to leverage corporate resources - but it proprietary software to assist with kernel patching, the use of Sun's Java instead of a "fully free" (in GNU terms) codebase, or a give-and-take with commercial developers - its not going to have its software reach a critical mass where Joe Manager can trust it enough to put his job on the line.
Wrong. The type of *foo could be absolutely anything. You happen to be forcing whatever it is to be viewed as being of type char. The only reason you get away with this is that you are using C/C++, which is not a strongly typed language.
Enough is enough. You are the sort of abject reprobate responsible for the vast amount of useless, redundant shit that pervades open/free software, and obscures the relatively small number of projects of real value.
Here's the short & sweet version: no docs means no interfaces/contracts on your functions, means no forethought, no checking, and buggy software which no-one else can use because they don't have a fucking clue what the thing does unless they read the entire fucking file to decipher the cryptic shit which YOU think is well written code.
A one-line description of WHAT a function does, coupled with assumptions about each parameter and what you can expect the function to return in normal and error conditions, is worth a shitload more than the implementation, which any kode kiddie can write.
It also means that you can read 20 lines and have an EXCELLENT knowledge of the entire capability of a 1000 line file, and how you may be able to reuse the code. Or that Joe Maintainer knows what the function is supposed to be doing instead of having to know the entire goddamn codebase and guess at the intended usage.
Or that kode kiddie #203987 on SourceForge doesn't have to start ANOTHER project to create a library when there are 80 already that (s)he doesn't understand how to use.
I would argue that int *foo means foo dereferenced is a segfault unless you've assigned a meaningful value to the pointer foo.
Or, to take your conclusion: In this: 'char foo, *bar', we declare that two things have type 'char': foo, and the thing that bar points to. Wrong, you haven't declared the thing that bar points to as type char. You haven't declared it at all. Which is precisely the sort of misunderstanding that I'm saying your style of declaration leads to.
In char *bar you have declared a pointer, and some assumptions about the pointer. You have not declared a char. There is no memory allocated to that char, nor any type checking implied about the value that bar may point to unless accessing it through bar. In other words, you have declared nothing at all about what bar points to, but rather a constraint on the use of the pointer bar.
In other words, char* foo clearly declared foo as a pointer, whereas char *foo defines *foo as a char, and by implication foo as a pointer, but no char is every actually declared.
You missed my point entirely. *foo is not a character. *foo is a pointer, and under ideal circumstances it is going to point to a character. *foo is not a character because you are not declaring a char variable, you are declaring a pointer variable.
Saying that *foo is a character implies that you can do something like *foo = 'A';. Which, surprising as it may seem, you can't. This is usually referred to as a "segfault" or "bug". But if you first assign a value to the pointer so that it actually points to something, then you can access a character at*foo.
OTOH, char* foo is arguably more logical than char *foo. You are declaring foo as being of type "character pointer". You are not, in fact, declaring a char with a pointer to it named foo (you never declared the char, only the pointer), which is what is implied by your recommended form.
I'm not sure of my figures, but I've been led to believe that a half decent programmer in America can expect upwards of $40k a year.
I'm going to take my country (South Africa) as an example here: $40k at the current exchange rate translates to about R400k (Rand) and some change. A full time employee (depending on city) is looking at R12k to R30k per month, and that's a good developer. Contractors expect anywhere up to double that.
So take 1 America developer salary for 6 months ($20k) and turn it into Rands, and you can pay 2 SA developers for 6 months, more or less.
Now you do the math: is my assumption of developer salary (US) correct? what is the cost of adding one developer to your office, versus the cost of funding a remote office (and most likely equipment) for non-local developers.
With more exact figures, you have a much better idea of the financial implications... but it doesn't really answer your question.
I have some experience in remote management. Not international, but I was not working with the development team, although I could meet with them (we did so monthly, but I could organise to meet on short notice).
My humble submissions from experience:
Control the development strictly from your side.
Ensure that you have a good design before getting the implementors (at remote sites) involved
Give each remote team a single task to complete, with clear expectations and deadlines. They will overrun (like any team) so factor that in. Also make it clear that coding to standards is part of the deliverable, and will be audited.
Essentially, each remote team delivers a complete, unit tested and auditable component before going on to the next bit.
It helps a lot if the remote team(s) know the Big Picture before starting with the implementation, even if the design is complete and well documented. Take the time to document the overall design and architecture clearly, so that everyone can understand it.
COMMUNICATE. All The Time. Get daily updates via e-mail, and if possible mirror their code updates daily, so you can monitor progress.
As part of communication, make it clear that overrunning is not the end of the world. But them hiding from you the fact that they MAY overrun is punishable by death. It is far more important to know the real situation and figure out how to deal with it, so make it clear that they won't be crapped out or otherwise contractually screwed, as long as they keep you informed.
Video-conference. Its a wonderful way to hold regular meetings, at fairly low cost (use Internet conferencing if possible, with a whiteboard app if necessary), where you can meaningfully interact with your developers.
Language barrier: I bring this up because you mentioned Indian developers. Some Indians are extremely fluent in English, others are weak. Understanding your intent, design and instructions is crucial to the success of the remote team (and, therefore, you). Video conference with any prospective team members first - that is, conduct remote interviews.
There's probably more, but my brain is starting to go squishy;)
Slashdot Mirror
Two words: freelance journalism
I'm hardly surprised. How can you understand functions and procedures without understanding the conceptual model of a functional program? How can you understand pointers, references and pass-by-value without understanding the execution model behind the program?
To teach, you have to start at the beginning. Programming is the means, which comes in just before the end. The approach of teaching students how to hack their way along in a visual language is a primary cause of the number of inept developers, and gives our profession a bad name. Bookkeeping is a well-established profession: if you get a useless bookkeeper, you blame the person or the institution. A useless developer is assumed to be par for the course.
Programming courses need to start with the most basic topic: what IS a program. Then the theory of how programs run (jumping around to repeat bits of processing, and varying the processing with parameters). Followed by how we achieve that using source code and a compiler.
Only then can a student appreciate and understand what they are going to be doing when they "program".
You are discussing the difference between maths, engineering and social science. Programming can unfortunately only be described as a social science subject.
In maths you are presented with the result (the theory), and then with the proof. You don't need to satisfy yourself that it is correct emperically or "in the real world" or that its better to do it that way. Its proven.
In engineering you are presented with the result. You don't care about the proof, because you know that there is research and proof underlying the result, and you use the result in the recommended way to achieve those ends.
In social science everyone has their own theory. Some people rise to the top of the pile, and get continually picked on. Occasionally someone provides sufficient emperical evidence to justify the result being called a fact within the subject's domain.
This is the case with subjects like psychology and computer science. There is always more than one way to do or interpret something, and ego dictates that you must contest "accepted facts", and either derive or disprove the result for yourself.
Programming SHOULD be taught as an engineering subject. There is a body of knowledge for programming according to the conceptual model in use, and it is based on hard evidence from decades of development.
Unfortunately, software engineers prefer to make their own cement rather than ask the expert cement maker for the properties of the cement that is readily available.
Some friendly advise from the Been There Done That department:
You clearly don't have a fucking clue about business, or business users, or business purchasers, or business administrators. Cost makes up a 10% sway on the final choice. Period.
Were this not the fact, Microsoft would not get away with fleecing 90% of the world's business users of $800 every two years for an operating system, office suite, and server licenses.
Even when there is a clearly better and cheaper alternative from a technical viewpoint, it will often not be chosen. Business attaches a high value to a high price, and is prepared to pay the price.
The support model doesn't work either. Business expects to BUY, not to license. Hence the exodus from MS at the moment. Buying makes them confident that they're getting a decent product (even when they're not) - paying for support means they KNOW they're getting shit.
Precisely. Some RMS's long diatribes about "free speech and not free beer" being the intention of the GPL are actually bullshit. He has actively prevented (through the GPL) there being the possibility of free speech without free beer.
Finally RMS shows his true colours. The UnitedLinux companies have guaranteed gratis access to the source code, which means free speech is satisfied. But despite RMS's continual statements that "its okay to sell GNU software", when it comes down to it, he's going to throw a frothy is your are giving it awat, gratis.
So much for free speech. RMS cares more about beer.
Oh dear, another file format debate. I'm glad there was a library suggestion though ... that allows us to change our mind when we do it wrong the first time ;)
First, you need to consider the possibilitiy of moving the mailbox. To a different computer, or a different platform. This means it must be easy to access in any environment, and the tools must be portable.
This doesn't completely rule out a database solution (like mySQL), but it certainly makes it less-than-ideal.
Second, having used many mailers which separate out attachments ... Please Don't Do It! You can't easily move your mailbox, because there are a host of associated attachment files. There is ALWAYS a synchronisation issue between attachments and messages, so you end up scanning and cleaning out the attachment folder every so often to prevent dead files from accumulating.
Compression is nifty, but isn't really important. Disk space is seldom a concern these days, and the really big stuff (binaries) is often already compressed or don't compress well.
The real issue with most mailbox formats is how do you deal with the problem of removing dead space from the mailbox? Some program just leave it there until you hit "compact", which is wasteful and confuses users. Others rewrite the entire mailbox every time, which causes the software to "hang" for a while on shutdown.
The best suggestion I can come up with off the top of my head is this: One file per mailbox folder, and that file is its own filesystem. The "root node" contains a group of summaries (from, to, subject, date, etc) and node links. Other nodes are chained to contain the message and attachments.
Handling attachments: attachments are separated out and stored as binary in the mailbox. This conserves space but keeps the attachment with the message.
Compacting: is avoided. When a mail is deleted, it is merely flagged in the root node (index). So each mailbox has its own deleted items folder, so to speak. When the deleted items folder is empties, the index is rewritten and nodes freed - every node not at the end of the file is overwritten with a node from the end of the file (and appropriate reindexing done), so the file is automatically compacted.
Ideally the file needs some sort of transation logging area to ensure its integrity at all times.
Shared access to files is best handled through a library or a service. File locking is notoriously prone to bugs and security issues, and avoiding multiple implementations in different mail clients would be beneficial.
I am fully versed in the FSF's philosophies. I just disagree with them. I do not find the GPL in the interests of "all computer users" because it has serious (negative) implications for creativity, standardization, and the sharing process.
RMS's rampant anti-Copyright arguments are fatally flawed in their assumption that software can exist in a form beneficial for all, without an economic model. RMS has also brainwashed people into accepting his explanation of "free speech" versus "free beer". The GPL enforces (not merely permits) "free speech", but also "free beer".
What this means for the man in the street is Bad News. Seeing a need, an industry can produce software to fulfil that need. In doing so it engages in economic activity, providing jobs to people like (surprise surprise) us. But if it must use the GPL, it can only be guaranteed a single sale. The first purchaser is permitted the rights to modify and redistribute the software, and resell it. No, not just it - but infinite copies, at any price (s)he choses. So it comes down to the fact that business cannot survive under an "only GPL" model.
On the flip side of the coin, let's assume that business is NOT involved. Free Software developers have got together and made a product. The end user STILL loses. Why? Because free software is notoriously shit compared to commercial alternatives when it comes to usability. It is typically made by geeks, for geeks. More specifically, the free software movement today is characterised by following. All of the features present in "productivity apps" (those which are of interest to normal home users) have debuted in commercial software, and the ideas simply copied.
All of this goes to say that the GPL stifles creativity. When there is no economic incentive, creativity declines.
Very few people benefit from the "freedom" offered by GPL software, unless we're talking "free beer". The vast majority of end users do not have the means to use the source code, and are confused and intimidated by the GPL. This reduces the sharing process. I am bound by severe legal constraints if I choose to give a copy of a GPL application to someone. I must include the source code (inconvenient, since I may not have chosen to obtain it), or provide an offer to provide the person with the source code. The GPL says it is NOT sufficient that I merely direct the recipient to the web site of the original source code (even if I haven't made any modifications), because as the distributor the onus is on ME to provide the source.
So much for easy sharing.
Which brings me to standardization, the central topic of my original post. Contrary to your belief, I don't want businesses to be treated as charities. I want meaningful contribution in both directions. And given the history of the situation, I don't believe this can be achieved using the GPL.
The FSF can treat itself as a sole light in the darkness of Copyright, fighting to bring a new age of Enlightenment to desktops near and far. And it can fail, because its efforts are continually divided by the (perceived) requirement to provide compatibility.
Or it can make reasonable efforts to reconcile its philosophy with that of the rest of the world, and work together nicely for a better future. And that means a give-and-take relationship with industry. "You can't have this unless you give us the commercial product its going to be a tiny part of" is not a give-and-take relationship.
The BSD license allows a business to benefit from free software. And it allows the business to contribute back in a manner it sees fit. A business almost certainly doesn't want to spend millions developing a commercial product, and then give it away for free (speech and/or beer), but it is likely to be willing to contribute extensions, fixes, and code that doesn't threaten its commercial model back into the free software space.
Or, to put it another way: if you don't give them anything, why the hell should they give something to you?
There are very few companies that can, or do, practice "embrace and extend". It only works effectively if you are a monopoly.
My point was very simply that the LGPL is itself a viral license: section 6 requires that a work linked to LGPL covered code be modifiable. It implies that object code (so that the work can be relinked against a modified version of the library) is sufficient, but this is unclear, as the section refers to two different things as constituting "a work".
At the very least, this means that if you use g++ to compile your C++ programs (which will then in all liklihood uses the facilities of libstdc++, which is covered by the LGPL) you must distribute the object files to allow relinked against a different version of libstdc++. At worst, it requires you to make your source code available to customers.
I agree with this position - business etiquette says go up the chain of command to get a message to someone in another department. Having said that, it can be useful to approach someone directly on an informal basis, assuming they are approachable.
In a breif and uncharacteristic defense of MCSEs (or MCNE), one entire non-elective module (out of 6 for an MCSE) is devoted to TCP/IP networking, from the ground up. The go over the OSI model extensively, and all of the TCP/IP theory. But they don't cover routing protocols (BGP, RIP, etc) in great detail, and they don't cover network security as a separate issue (i.e. you are trained to maintain and diagnose a network, and told to get an expert to deal with firewalls).
Ensuring freedom for who, exactly? When I develop software "for free", I want people to use it. The more people use common libraries, the less we are faced with a diversity of protocols and formats. That means commercial organisations too - FSF/OSS developers spend most of their time playing "compatibility catchup".
But most importantly, the GPL fails in its efforts to encourage code sharing, because it locks out the largest potential resource of high-quality, useful code: business.
Business can't use GPL code in its products, and is skeptical about LGPL (with good reason: see section 6 of the LGPL!). So it doesn't use (L)GPL code, doesn't contribute back (via testing, maintenance or extension), and neither side benefits. The only time businesses LIKE the GPL is when they release their own code, because it restricts competitors from using it.
BSD licenses OTOH allow everyone to share. Sure, some people abuse the situation. But the community loses nothing in real terms.
Frankly, this scares the shit out of me. It gives carte blanch for any intended user to modify the work, which implies (without saying so explicitly) the availability of source code.
Now put this in the context of using C++ compiled with GCC. The binary must be linked against libstdc++, which is LGPL.
Unless I'm going completely off the wall, this says that any C++ program compiled with GCC must have its source available to customers. Viral indeed!
Does someone want to tell me if I've lost the plot, and why?
OS/2 was a cooperative project between IBM and MS. IBM designed and wrote the low-level stuff, including the kernel, security system, object system, and object communication (OLE, DDE, etc). MS did the pretty stuff on top, all the while putting more work into Windows 3.0.
When Windows was ridiculously more successful than OS/2, MS licensed a huge amount of IBMs technology behind OS/2, defined a 32 bit API (which evolved slightly to become the Win32 API) and build NT. In the process they removed all of the crap that made OS/2 difficult to use. We know that crap better as "security features" and "robust object model".
(No, this is not a joke. MS intentionally removed a whole lot of security from IBM's code to create NT 3.1 and 3.51. Then it removed even more to create NT 4.0. The original design was sufficient for Orange book B1 classification.
This is bulshit which is only allowed to survive because no-one raises complaints against company directors for neglecting their fidiciary duty.
A company is a juristic person, and the directors are entrusted with making decisions on behalf of the company. Their behaviour is described fidiciary duty, and includes as two of its most important requirements the wellbeing of the COMPANY (not the shareholders) and that the company act in a manner consistent with the law (i.e. the directors are its morality and conscience).
A company which screws its support base in order to make money is NOT acting in its best interests. If such action is taken and doubt is cast by the market on the long-term viability of the company, then the directors may have failed in their fidiciary duty, and any shareholder can raise a complaint with the appropriate body.
Has anyone actually bothered to read these patents? I've browsed through half of the /. comments so far, and seen only patents vs. the GPL arguments. Where this any other company being discussed, they would have been shredded for patenting the patently obvious.
The first patent covers an HTTP server in kernel space which caches static and dynamic parts of pages separately. Yay. ASP (with caching on) and JSP do exactly this, but not in kernel space (at least, we're assuming ASP doesn't run in kernel space). So they're going to patent something because they were the first to think of putting it into the kernel (supposedly). What complete bullshit!
The second patent is even more ludicrous. Keep a cache of open files (name->handle map by implication) to improve performance - you don't have to open the file again if its already open. Heck, why didn't I think of that?! Ooops, I did. Used it several times.
RedHat has not invented anything. Its filing for bogus patents, probably as a defensive tactic. And as the GNU proponents have kindly pointed out, RedHat is fscked if it doesn't license the patents appropriate (to allow free software development) because they will then be violating the GPL by integrating TUX into the kernel. And if they don't do this then TUX won't be covered by their patent. Doh!
Maybe somebody needs to gather hard evidence of prior art an sumit it to the USPTO before they award this patent ...?
This sort of high-profile case is just crying out for a shown of public support. Do you think a couple of free software heavyweights could agree on a middle-of-the-road viewpoint on Copyright law (by which I mean somewhere other than abolish it) in a form that "open IP" supporters everywhere (or just in the US ;) ) could "sign" in an online show of support.
The recent /. article on Copyright would probably been a good place to look for ideas ;)
An excellent reply :) I feel it necessary to add my 2c though ...
In both scenarios (refugee/goldrush) Copyright does not enter the picture. Copyright is not about restricting the free flow of information; it is about restricting the free copying of a particular incarnation of that information.
Fact #1: You can't copyright a fact. You can copyright the exact sequence of words you use to express a fact, but that doesn't prevent someone from reading that fact and telling someone else or writing it down in his/her own words.
Copyright as applied to facts encourages authors/publishers to put facts into words because they can receive remuneration for a collection of facts (a work). Without copyright on works of fact there would be no incentive to record facts, and we would rely on the facts recorded by a small number of altruists.
Fact #2: You can copyright a fiction. If you have made something up, it is not information. It is a fabrication. Here copyright is not restricting the free flow of information, but the reproduction of a creation.
Without copyright in this scenario, authors have no incentive to create, because their creation can be duplicated without them receiving anything (fame OR fortune).
--end of 2c--
You draw a distinction between "inside" and "outside" the company, as does the GPL (I agree). I do not know if US law permits this distinction, but SA law does not. A company is a separate, opaque, legal person. Employees cannot be "inside" a company for any legal purpose. They may have a contract with a company, but they are in no way part of the company, any more than you are part of your best friend (excluding spouses).
So you then have to decide how software works in this model. Is the company the owner, and allowing you to use the software it owns as a sort of service? Or does the company effectively transfer that license to you for the duration of your contract, since you are a separate legal entity to the company?
This presents an interesting legal challange in the case of commercial software too. If you have per user licensing of an MS operating system, for example, you have the right to install and use that OS on your home computer in addition to your work computer, providing you are the (sole/primary) user of both systems. Why? Because from the legal viewpoint the company transfers the right of license to you as part of your contract of employment.
In the GPL case, the company has the choice of providing software or service, and this may be a way around the catch-22 in our legal system. But the point nevertheless stands that this IS a legal minefield for the uninitiated.
It is an accepted wisdom that too much of anything is a bad thing; that includes too much freedom. RMS has too much rope, and is hanging free software in general.
Why do I make such sweeping claims? First, RMS is against proprietary software in any form. This is inherently self-defeating: the developers who work on free software can't do so for free. Industry has proven that the support model is nowhere near as effective as the software sale model, which means that the support model can't sustain enough developers to ensure the progression of software.
RMS's views have also shown themselves to be ineffective in stimulating innovation, something that should be rife in the free software community. Free software in general has been a technology follower for years, and its getting worse. Monitor the news on FSF/OSS sites and all you see is new projects which are trying to clone commercial products or architectures.
One of the reasons for this continual game of catch-up is that there is no scope for sharing of GNU source code with companies - in either direction. A company cannot license its code or binaries in a way that will allow it to persue the software sale model AND make RMS happy. So GNU developers must make their own version from scratch in order to achieve compatibility.
Conversely, companies are provided with no incentive to use GNU software in their products. At a push they may use software under the LGPL, but without such incentives to companies, they will not allocate corporate resources to activities which ultimately could (not necessarily would) improve the quality, functionality or quantity of free software. The worst part is that because companies don't reuse free software, but build their own, they have their own unique bugs and "features", which obviously cause imcompatibilities with other implementations ... which they don't correct. So it comes back to the GNU developers to make further additions to their software to support the incompatibilities.
So basically not having a way to share between GNU software and commercial software bites free software in a number of ways.
In my dealings with pro-GNU people I've been astounded to found how some of them have their heads so far up their arses that they are completely unaware of the state of commercial software, the features available, etc. I still hear claims like "Windows sucks - it crashes 5 times a day" being made seriously. Sure, my Windows 2000 box has crashed 5 times in the last 3 months. This was due to power failures. And I lost nothing, unlike the Linux box which couldn't boot after the second crash. But I digress (somewhat)...
How can hardcode GNU/free software supporters make claims about software they have never used? Or should I rather ask: how can the Pope understand Hinduism?
But the most debilitating of RMS's activities is his persuit of trying to convince all free software developers to use the GNU license. Thanks to Microsoft's tactics and, in part, RMSs responses, industry is very skeptical about using GNU software. This makes it extremely difficult to broaden the scope of Linux usage.
Here is an extreme case: a company wants to rid itself of Windows, and rolls out Linux workstations to all of its employees. Catch 22: the employees have the right to the source code for Linux, since you are providing them with binaries for their use; but the employees by contract are only allowed to use the computers for approved activites, which does not require the availability or use of the Linux source code. This is not a silly construct, it is a serious legal opinion (not originating from myself).
Misunderstanding of the GPL is as rife as misunderstanding of the MS EULA. The presence of viral clauses is enough to make bean counters shit themselves without fully understanding the implications.
In general, RMS doesn't seem to understand that companies don't give a shit about the availability of source code. Corporate governance isn't about technically sound solutions, its about arse covering. Pay for a commercial product, and you can expect support (even if you have to pay). It may cost more, but when all hell breaks loose you can say "I did my homework, I paid for support, its their problem now". There is no "if" about hell breaking loose - you have to assume it WILL happen. And you need to be covered.
RMS encourages the support model for free software, but its not breaking into the market because GNU software can't keep pace with corporate resources.
Until the FSF learns to leverage corporate resources - but it proprietary software to assist with kernel patching, the use of Sun's Java instead of a "fully free" (in GNU terms) codebase, or a give-and-take with commercial developers - its not going to have its software reach a critical mass where Joe Manager can trust it enough to put his job on the line.
Wrong. The type of *foo could be absolutely anything. You happen to be forcing whatever it is to be viewed as being of type char. The only reason you get away with this is that you are using C/C++, which is not a strongly typed language.
<FLAME>
Enough is enough. You are the sort of abject reprobate responsible for the vast amount of useless, redundant shit that pervades open/free software, and obscures the relatively small number of projects of real value.
Here's the short & sweet version: no docs means no interfaces/contracts on your functions, means no forethought, no checking, and buggy software which no-one else can use because they don't have a fucking clue what the thing does unless they read the entire fucking file to decipher the cryptic shit which YOU think is well written code.
A one-line description of WHAT a function does, coupled with assumptions about each parameter and what you can expect the function to return in normal and error conditions, is worth a shitload more than the implementation, which any kode kiddie can write.
It also means that you can read 20 lines and have an EXCELLENT knowledge of the entire capability of a 1000 line file, and how you may be able to reuse the code. Or that Joe Maintainer knows what the function is supposed to be doing instead of having to know the entire goddamn codebase and guess at the intended usage.
Or that kode kiddie #203987 on SourceForge doesn't have to start ANOTHER project to create a library when there are 80 already that (s)he doesn't understand how to use.
</FLAME>
I would argue that int *foo means foo dereferenced is a segfault unless you've assigned a meaningful value to the pointer foo.
Or, to take your conclusion: In this: 'char foo, *bar', we declare that two things have type 'char': foo, and the thing that bar points to. Wrong, you haven't declared the thing that bar points to as type char. You haven't declared it at all. Which is precisely the sort of misunderstanding that I'm saying your style of declaration leads to.
In char *bar you have declared a pointer, and some assumptions about the pointer. You have not declared a char. There is no memory allocated to that char, nor any type checking implied about the value that bar may point to unless accessing it through bar. In other words, you have declared nothing at all about what bar points to, but rather a constraint on the use of the pointer bar.
In other words, char* foo clearly declared foo as a pointer, whereas char *foo defines *foo as a char, and by implication foo as a pointer, but no char is every actually declared.
You missed my point entirely. *foo is not a character. *foo is a pointer, and under ideal circumstances it is going to point to a character. *foo is not a character because you are not declaring a char variable, you are declaring a pointer variable.
Saying that *foo is a character implies that you can do something like *foo = 'A';. Which, surprising as it may seem, you can't. This is usually referred to as a "segfault" or "bug". But if you first assign a value to the pointer so that it actually points to something, then you can access a character at *foo.
OTOH, char* foo is arguably more logical than char *foo. You are declaring foo as being of type "character pointer". You are not, in fact, declaring a char with a pointer to it named foo (you never declared the char, only the pointer), which is what is implied by your recommended form.
I'm not sure of my figures, but I've been led to believe that a half decent programmer in America can expect upwards of $40k a year.
I'm going to take my country (South Africa) as an example here: $40k at the current exchange rate translates to about R400k (Rand) and some change. A full time employee (depending on city) is looking at R12k to R30k per month, and that's a good developer. Contractors expect anywhere up to double that.
So take 1 America developer salary for 6 months ($20k) and turn it into Rands, and you can pay 2 SA developers for 6 months, more or less.
Now you do the math: is my assumption of developer salary (US) correct? what is the cost of adding one developer to your office, versus the cost of funding a remote office (and most likely equipment) for non-local developers.
With more exact figures, you have a much better idea of the financial implications ... but it doesn't really answer your question.
I have some experience in remote management. Not international, but I was not working with the development team, although I could meet with them (we did so monthly, but I could organise to meet on short notice).
My humble submissions from experience:
There's probably more, but my brain is starting to go squishy ;)