Slashdot Mirror

The list is all about combating newspeak and doublethink. Confusing libre (freesp) with gratis (freeb) is just what Microsoft want you to do, so they can call Explorer "free" software. Didn't you see http://www.icq.com? They claim to offer free software.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^HPerl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Others have explained it better than I have. Try this link: free software

Because they can. Software titles are often cracked / downloaded just because they are very expensive and exotic.

This software writer should have little concern about loss of revenue for many of the reasons mentioned in earlier threads. I suspect he simply wants publicity.

Also please do not use the term piracy, sharing is a good substitute.

The same with books!

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD, erm, Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Linux on the desktop still needs some serious work before it can become mainstream.

I think the question shows a fundamental misunderstanding by asking us to say whether we think the philosophy is more important or the quality of the software and by making the statement "as embarrassing commercialism is against the freedom of Open Source Software." Open source is not about eliminating commercialism or business. Despite comments often made to the contrary, most open source/free software advocates are not Communist, anti-capitalist, or anti-business. Please see also RMS's comments about how commercial and free software are not mutually exclusive and selling free software.

Advertising in open source/free software would not be a sacrifice of principle. That said, I seriously doubt it would help the quality of the software, either.

I think the question shows a fundamental misunderstanding by asking us to say whether we think the philosophy is more important or the quality of the software and by making the statement "as embarrassing commercialism is against the freedom of Open Source Software." Open source is not about eliminating commercialism or business. Despite comments often made to the contrary, most open source/free software advocates are not Communist, anti-capitalist, or anti-business. Please see also RMS's comments about how commercial and free software are not mutually exclusive and selling free software.

Advertising in open source/free software would not be a sacrifice of principle. That said, I seriously doubt it would help the quality of the software, either.

Fair enough...
RAND = Reasonable And Non-Discriminatory Licensing.
This is what RMS thinks about it.

W3C = World Wide Web Consortium.

It's still probably helpful to know where you can obtain and learn to use a MIPS VM. Check out the GNU MDK manual Contains the MIX instruction set and a programming tutorial, as well as documentation on using the VM itself.

For the intro:

In his book series The Art of Computer Programming (published by Addison Wesley), D. Knuth uses an imaginary computer, the MIX, and its associated machine-code and assembly languages to ilustrate the concepts and algorithms as they are presented.

The MIX's architecture is a simplified version of those found in real CISC CPUs, and the MIX assembly language (MIXAL) provides a set of primitives that will be very familiar to any person with a minimum experience in assembly programming. The MIX/MIXAL definition is powerful and complete enough to provide a virtual development platform for writing quite complex programs, and close enough to real computers to be worth using when learning programming techniques. At any rate, if you want to learn or improve your programming skills, a MIX development environment would come in handy.

The MDK package aims at providing such virtual development environment on a GNU box. Thus, MDK offers you a set of utilities to simulate the MIX computer and to write, compile, run and debug MIXAL programs.

I know this is not a commercial project in a large corporation, I thought I mention it anyway. In the GnuGo project we have a large set of simple test scripts, and all the time we keep track of which of them succeed, and which fail. There are always some failures, but we can live with that (we sort of have to). This test set has saved us a lot of time. It has also given valuable information on the effects of a new algorithm or piece of code, or what happens when you adjust some tunable parameters. No expensive tools used, just a bit extra coding to make all the necessary information available for the tests, and a few scripts...

What's wrong with this logo?

Sorry...I know. Trolling. But what else is karma for?

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD, erm, Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

It's called limegreen, because some people out there seem to feel that it is more important that a web site has got a cool logo, in some trendy colour like limegreen, than that it actually works.

// Ulf Härnhammar

"I get my pay from germany with paypal, if they change it to you can only use your paypal money to pay for ebay stuff, ebay will gain, but we will all be stuffed."

"I get my pay from germany with paypal, if they change it to you can only use your paypal money to pay for ebay stuff, ebay will gain, but we will all be stuffed."

Well, maybe the wave of the future won't be "GPL" but "FDL"

We somehow opened the world of information to us with the internet but now it's going to be closed to a pin-hole size.

Newspapers and books? How long will those be allowed to exist in their current forms? Paper?!?! How insecure! There will be e-books and e-paper, as in Minority Report. And you won't have control over those either.

Stallman's "Right to Read"

I guess, what doesn't kill us makes us stupid.

GNU project page

GNU project page

Better yet, if an architecture has a static branch predictor that encodes "mostly taken" or "mostly not taken", the compiler could emit profile code that measures how fast a particular variant runs and then take that into account for the next optimization pass.

Come on: read and think. gprof wasn't working multithreaded because it was getting its signal only in the main thread. And read the documentation.

Actually, this article is a pretty good critism on Stallman's position. He believes that people don't necessarily need to be paid to write good software. That a cause is good enough. Afterall, that is the exact reason this whole movement was started -- with Stallman quitting MIT and beginning to write GNU. For those of you unfamiliar with it, let me post and excert from the GNU Manifesto:

Why I Must Write GNU

I consider that the golden rule requires that if I like a program I must share it with other people who like it. Software sellers want to divide the users and conquer them, making each user agree not to share with others. I refuse to break solidarity with other users in this way. I cannot in good conscience sign a nondisclosure agreement or a software license agreement. For years I worked within the Artificial Intelligence Lab to resist such tendencies and other inhospitalities, but eventually they had gone too far: I could not remain in an institution where such things are done for me against my will.

So that I can continue to use computers without dishonor, I have decided to put together a sufficient body of free software so that I will be able to get along without any software that is not free. I have resigned from the AI lab to deny MIT any legal excuse to prevent me from giving GNU away.

So it should be clear that money wasn't a factor in Stallman's decision to write GNU. I think this is echoed repeatedly since -- people don't typically write free software to make money.

But perhaps the real problem with the KDE project is that people write code for the same reason Linus says he writes code, for the joy of it. With this motivation, there is no room to code for other people. Writing still becomes a selfish activity -- only released freely for other people to use.

Most people here know the history of the KDE and GNOME projects and how GNOME was a response to KDE. Perhaps this was a more of a division on principle than we had thought. That GNOME developers are slightly more inclined to develop to bring people freedom than KDE, which is more of hobbyist group. And when your motivation is freedom, users *do* factor into the equation.

However, its probably more likely that GNOME simply has more paid developers than KDE. But I think the speculation above is valid at some level.

This paper analyzes the amount of source code in GNU/Linux, using Red Hat Linux 7.1 as a representative GNU/Linux distribution, and presents what I believe are interesting results.

In particular, it would cost over $1 billion ($1,000 million - a Gigabuck) to develop this GNU/Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars). Compare this to the $600 million estimate for Red Hat Linux version 6.2 (which had been released about one year earlier). Also, Red Hat Linux 7.1 includes over 30 million physical source lines of code (SLOC), compared to well over 17 million SLOC in version 6.2. Using the COCOMO cost model, this system is estimated to have required about 8,000 person-years of development time (as compared to 4,500 person-years to develop version 6.2). Thus, Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2. This is due to an increased number of mature and maturing open source / free software programs available worldwide.

Many other interesting statistics emerge. The largest components (in order) were the Linux kernel (including device drivers), Mozilla (Netscape's open source web system including a web browser, email client, and HTML editor), the X Window system (the infrastructure for the graphical user interface), gcc (a compilation system), gdb (for debugging), basic binary tools, emacs (a text editor and far more), LAPACK (a large Fortran library for numerical linear algebra), the Gimp (a bitmapped graphics editor), and MySQL (a relational database system). The languages used, sorted by the most lines of code, were C (71% - was 81%), C++ (15% - was 8%), shell (including ksh), Lisp, assembly, Perl, Fortran, Python, tcl, Java, yacc/bison, expect, lex/flex, awk, Objective-C, Ada, C shell, Pascal, and sed.

The predominant software license is the GNU GPL. Slightly over half of the software is simply licensed using the GPL, and the software packages using the copylefting licenses (the GPL and LGPL), at least in part or as an alternative, accounted for 63% of the code. In all ways, the copylefting licenses (GPL and LGPL) are the dominant licenses in this GNU/Linux distribution. In contrast, only 0.2% of the software is public domain.

This paper is an update of my previous paper on estimating GNU/Linux's size, which measured Red Hat Linux 6.2 [Wheeler 2001]. Since Red Hat Linux 6.2 was released in March 2000, and Red Hat Linux 7.1 was released in April 2001, this paper shows what's changed over approximately one year. More information is available at http://www.dwheeler.com/sloc. 1. Introduction The GNU/Linux operating system has gone from an unknown to a powerful market force. Netcraft found that, of the systems running web servers on June 2001, GNU/Linux was now the second most popular operating system (with 29.6%, versus Windows' 49.6%) [Netcraft 2001]. Another survey, of primarily European and educational sites, found that GNU/Linux was used more than any other operating system (of the sites it surveyed) [Zoebelein 1999]. IDC found that 25% of all server operating systems purchased in 1999 were GNU/Linux, making it second only to Windows NT's 38% [Shankland 2000a].

There appear to be many reasons for this, and not simply because GNU/Linux can be obtained at no or low cost. For example, experiments suggest that GNU/Linux is highly reliable. A 1995 study of a set of individual components found that the GNU and GNU/Linux components had a significantly higher reliability than their proprietary Unix competitors (6% to 9% failure rate with GNU and Linux, versus an average 23% failure rate with the proprietary software using their measurement technique) [Miller 1995]. A ten-month experiment in 1999 by ZDnet found that, while Microsoft's Windows NT crashed every six weeks under a ``typical'' intranet load, using the same load and request set the GNU/Linux systems (from two different distributors) never crashed [Vaughan-Nichols 1999].

However, possibly the most important reason for GNU/Linux's popularity among many developers and users is that its source code is generally ``open source software'' and/or ``free software''. A program that is ``open source software'' or ``free software'' is essentially a program whose source code can be obtained, viewed, changed, and redistributed without royalties or other limitations of these actions. A more formal definition of ``open source software'' is available from the Open Source Initiative [OSI 1999], a more formal definition of ``free software'' (as the term is used in this paper) is available from the Free Software Foundation [FSF 2000], and other general information about these topics is available at Wheeler [2000a]. Quantitative rationales for using open source / free software is given in Wheeler [2000b]. The GNU/Linux operating system is actually a suite of components, including the Linux kernel on which it is based, and it is packaged, sold, and supported by a variety of distributors. The Linux kernel is ``open source software''/``free software'', and this is also true for all (or nearly all) other components of a typical GNU/Linux distribution. Open source software/free software frees users from being captives of a particular vendor, since it permits users to fix any problems immediately, tailor their system, and analyze their software in arbitrary ways.

Surprisingly, although anyone can analyze GNU/Linux for arbitrary properties, I have found little published analysis of the amount of source lines of code (SLOC) contained in a GNU/Linux distribution. Microsoft unintentionally published some analysis data in the documents usually called ``Halloween I'' and ``Halloween II'' [Halloween I] [Halloween II]. Another study focused on the Linux kernel and its growth over time is by Godfrey [2000]; this is an interesting study but it focuses solely on the Linux kernel (not the entire operating system). Paul G. Allen posted some results from running Scientific Toolworks, Inc.'s tools on the Linux kernel, but this analysis only considered C code (including headers) - ignoring the many other languages used in constructing the Linux kernel (e.g., assembly language), and only concentrating on the kernel. The Free Code Graphing Project at http://fcgp.sourceforge.net generates a graphical representation of a program (currently, the Linux kernel), but only of the C code. In a previous paper, I examined Red Hat Linux 6.2 and the numbers from the Halloween papers [Wheeler 2001].

This paper updates my previous paper, showing estimates of the size of one of today's GNU/Linux distributions, and it estimates how much it would cost to rebuild this typical GNU/Linux distribution using traditional software development techniques. Various definitions and assumptions are included, so that others can understand exactly what these numbers mean. I have intentionally written this paper so that you do not need to read the previous version of this paper first.

For my purposes, I have selected as my ``representative'' GNU/Linux distribution Red Hat Linux version 7.1. I believe this distribution is reasonably representative for several reasons:

1. Red Hat Linux is the most popular Linux distribution sold in 1999 according to IDC [Shankland 2000b]. Red Hat sold 48% of all copies in 1999; the next largest distribution in market share sales was SuSE (a German distributor) at 15%. Not all GNU/Linux copies are ``sold'' in a way that this study would count, but the study at least shows that Red Hat's distribution is a popular one.
2. Many distributions (such as Mandrake) are based on, or were originally developed from, a version of Red Hat Linux. This doesn't mean the other distributions are less capable, but it suggests that these other distributions are likely to have a similar set of components.
3. All major general-purpose distributions support (at least) the kind of functionality supported by Red Hat Linux, if for no other reason than to compete with Red Hat.
4. All distributors start with the same set of open source software projects from which to choose components to integrate. Therefore, other distributions are likely to choose the same components or similar kinds of components with often similar size for the same kind of functionality.

Different distributions and versions would produce different size figures, but I hope that this paper will be enlightening even though it doesn't try to evaluate ``all'' distributions. Note that some distributions (such as SuSE) may decide to add many more applications, but also note this would only create larger (not smaller) sizes and estimated levels of effort. At the time that I began this project, version 7.1 was the latest version of Red Hat Linux available, so I selected that version for analysis.

Note that Red Hat Linux 6.2 was released on March 2000, Red Hat Linux 7 was released on September 2000 (I have not counted its code), and Red Hat Linux 7.1 was released on April 2001. Thus, the differences between Red Hat Linux 7.1 and 6.2 show differences accrued over 13 months (approximately one year).

Clearly there is far more open source / free software available worldwide than is counted in this paper. However, the job of a distributor is to examine these various options and select software that they believe is both sufficiently mature and useful to their target market. Thus, examining a particular distribution results in a selective analysis of such software.

Section 2 briefly describes the approach used to estimate the ``size'' of this distribution (more details are in Appendix A). Section 3 discusses some of the results. Section 4 presents conclusions, followed by an appendix. GNU/Linux is often called simply ``Linux'', but technically Linux is only the name of the operating system kernel; to eliminate ambiguity this paper uses the term ``GNU/Linux'' as the general name for the whole system and ``Linux kernel'' for just this inner kernel. 2. Approach My basic approach was to:

1. install the source code files in uncompressed format; this requires carefully selecting the source code to be analyzed.
2. count the number of source lines of code (SLOC); this requires a careful definition of SLOC.
3. use an estimation model to estimate the effort and cost of developing the same system in a proprietary manner; this requires an estimation model.
4. determine the software licenses of each component and develop statistics based on these categories.

More detail on this approach is described in Appendix A. A few summary points are worth mentioning here, however. 2.1 Selecting Source Code

I included all software provided in the Red Hat distribution, but note that Red Hat no longer includes software packages that only apply to other CPU architectures (and thus packages not applying to the x86 family were excluded). I did not include ``old'' versions of software, or ``beta'' software where non-beta was available. I did include ``beta'' software where there was no alternative, because some developers don't remove the ``beta'' label even when it's widely used and perceived to be reliable.

I used md5 checksums to identify and ignore duplicate files, so if the same file contents appeared in more than one file, it was only counted once (as a tie-breaker, such files are assigned to the first build package it applies to in alphabetic order).

The code in makefiles and Red Hat Package Manager (RPM) specifications was not included. Various heuristics were used to detect automatically generated code, and any such code was also excluded from the count. A number of other heuristics were used to determine if a language was a source program file, and if so, what its language was.

Since different languages have different syntaxes, I could only measure the SLOC for the languages that my tool (sloccount) could detect and handle. The languages sloccount could detect and handle are Ada, Assembly, awk, Bourne shell and variants, C, C++, C shell, Expect, Fortran, Java, lex/flex, LISP/Scheme, Makefile, Objective-C, Pascal, Perl, Python, sed, SQL, TCL, and Yacc/bison. Other languages are not counted; these include XUL (used in Mozilla), Javascript (also in Mozilla), PHP, and Objective Caml (an OO dialect of ML). Also code embedded in data is not counted (e.g., code embedded in HTML files). Some systems use their own built-in languages; in general code in these languages is not counted.

That's actually the whole point of copyright. Contrary to popular belief, copyright isn't "incentive" or motivation. A person's motivation for creating art (any book/film/music, etc.) is his passion for that art. Copyright is just a way of financing him. It's to make sure we don't have talented people out there who would've made valuable art, but didn't because they had to keep a day job. Copyright isn't supposed to motivate people through dreams of becoming rich, because such dreams never lead to good art. Inspiration leads to good art, and, in fact, many studies indicate that excessive rewards lead to less creative work. motivation

So there is a very effective social model that can increase culture while still providing an income for artists. Have the copyright end after 12 years. It's that simple.

Overall, on average, art only makes 10% of it's revenues after those 12 years.

Seriously, try it out. It's absolutely wonderful. By far the best way I've found to keep your system from accumulating too much cruft (well, it won't stop the accumulation, but it will make it trivially easy to get rid of later). I've only used Encap, but it's way way cool. When you compile a program, use "--prefix=/usr/local/encap/program-1.0" with the configure script, and then you'll have /usr/local/encap/program-1.0/bin, /usr/local/encap/program-1.0/share, etc . . . Then you run "epkg -i program" and it'll install all the symlinks correctly into /usr/local the way you'd expect. Then you can remove packages, upgrade, etc, etc, etc. Very fun.

Let's take this a step further. Software developers obviously are greedy people. I personally believe in free software and I think that there's no alternative to the quality and warranty guaranteed by it. These people who develop free software obviously make enough money off of it to not have to resort to commercial software

If you work at a commercial development software, I suggest you leave immediately. Open Source Software has been shown to increase profits ten-fold and guarantee business security. To those who call software dirty GNU hippies, well I have four words for you:

LOOK WHO'S LAUGHING NOW!

Sure, It's nice that it's there, but to really learn math, you will need to take classes.
Mathworld is good for quick-reference definitions and theorem statements, but it's tough to learn from it.

If you're going to plug math content sites on Slashdot, though, you might as well plug PlanetMath, which in addition to being freely accessible, has all of its content published under the GNU Free Documentation License.

The imaginary day in the not-too-distant future is described at the GNU web site.

If you find the first post informative you should better have a look at "Free Software".
That's really informative.

You make it sound like there are citizen uprisings in those cities. It turns out that the article you link to is merely about the LEADERS (not even the citizens) of a few cities passing a few silly resolutions that don't have the effect of undermining the government's authority one bit.

AND NOW FOR SOMETHING COMPLETELY ON-TOPIC.

I'd rather read the trivial news about SSH. The company mentioned that "doesn't use freeware" is just being stupid. The FSF has a link to a paper that debunks their fear about OpenSSH and other open-source "freeware" being "unsupported".

Also, like nearly everyone else, I recommend PuTTY if you need a Windows SSH client. Too bad that it's "freeware" too. I guess your company will have to settle for an inferior proprietary alternative.

Drop the vendor: they obviously haven't got a clue what they're talking about.

1) They should read their vendors' EULA's (and probably their own). No software these days is supported. ("This software is provided "AS IS"...).

2) Lots of free software is very much industry proven.

Perhaps you could try a little education.

Explain to them that it isn't freeware, it's Free Software.

Does SmartFilter gnu.org as a religious web site?

You fundamentally don't understand the GPL in associating what you said with it. Go read it and become educated before posting.

I have yet to see a native java app, show me one.

Lazy, ignorant, demanding SOB, aren't you? Okay, take a look at XWT, for one. Also take a look here and here.

Of course, the executable for a native Java app isn't going to look any different to the casual file(1) command than one compiled from C, C++ or even Fortran.

gcj, as someone else mentioned, is from the GNU project. It can even compile byte-code to machine code. Also, some JVM's are faster than others. A JVM with a just-in-time compiler (JIT) runs much faster. btw, I have an athlon 750 and when I run jedit, I don't notice any slowdowns.

No punt intended. But how can you "control" someting you put under GPL? You gave up all control. The only thing you still can consider to have is some kind of "meta control". If you liek to control your software or your IP GPL is surely only under raw circumstances the right thing.

I think the general gist of Stallman's comment isn't that you control the code, but that you're fully in charge of compiled code (software) on your own machine(s), versus the level of control one would supposedly have under a Microsoft-based software solution.

(BTW, did I include enough citations? I don't want to be accused of ripping anyone off)

No punt intended. But how can you "control" someting you put under GPL? You gave up all control. The only thing you still can consider to have is some kind of "meta control". If you liek to control your software or your IP GPL is surely only under raw circumstances the right thing.

I think the general gist of Stallman's comment isn't that you control the code, but that you're fully in charge of compiled code (software) on your own machine(s), versus the level of control one would supposedly have under a Microsoft-based software solution.

(BTW, did I include enough citations? I don't want to be accused of ripping anyone off)

No punt intended. But how can you "control" someting you put under GPL? You gave up all control. The only thing you still can consider to have is some kind of "meta control". If you liek to control your software or your IP GPL is surely only under raw circumstances the right thing.

I think the general gist of Stallman's comment isn't that you control the code, but that you're fully in charge of compiled code (software) on your own machine(s), versus the level of control one would supposedly have under a Microsoft-based software solution.

(BTW, did I include enough citations? I don't want to be accused of ripping anyone off)

No punt intended. But how can you "control" someting you put under GPL? You gave up all control. The only thing you still can consider to have is some kind of "meta control". If you liek to control your software or your IP GPL is surely only under raw circumstances the right thing.

I think the general gist of Stallman's comment isn't that you control the code, but that you're fully in charge of compiled code (software) on your own machine(s), versus the level of control one would supposedly have under a Microsoft-based software solution.

(BTW, did I include enough citations? I don't want to be accused of ripping anyone off)

No punt intended. But how can you "control" someting you put under GPL? You gave up all control. The only thing you still can consider to have is some kind of "meta control". If you liek to control your software or your IP GPL is surely only under raw circumstances the right thing.

I think the general gist of Stallman's comment isn't that you control the code, but that you're fully in charge of compiled code (software) on your own machine(s), versus the level of control one would supposedly have under a Microsoft-based software solution.

(BTW, did I include enough citations? I don't want to be accused of ripping anyone off)

> "The Linux OS?! when did that come out?"

Sigh.

&lt bite&gt Some time in 1991, Let met quote from the www.linux.org webpage: "Linux is a free Unix-type operating system originally created by Linus Torvalds with the assistance of developers around the world."&lt/bite&gt

Insisting on calling Linux "GNU/Linux systems" is like insisting on calling a car a "horseles carriage".

Wat we call Linux today is an OS, deal with it.

Note that there are also other OS's that use FSF/GNU tools (such as the gcc compiler). You can find some more information here.

And if you put the representatives from those three websites in the same room, you've got yourself a really nice family reunion: they're all related but they don't really enjoy it. But they are family and will have to get over it.

Basically, Eben Moglen, general legal counsel for GNU, was saying that GPL is safe because it does not restrict things that you are entitled to by other laws (ie. fair-use etc). The article is a good read.

Actually you did. I read it right off the link that he posted, you basically took a sentence from the page and altered it to reflect DotGNU rather than Mono.

It has nothing to do with dotgnu? Maybe you should learn how to read. That message was also sent to the dotgnu mailing list, which you SIGN UP FOR AT dotgnu.org. Since he didn't have a direct link to his EMAIL INBOX, he linked dotgnu.org. I think it's time to unbunch your panties, and move on with your life.

The stallman interview isn't even fucking about dotgnu. You stole stallman's words and put in a few hyperlinks.

Tell that to Richard Stallman:
Richard M. Stallman, founder of the GNU project and president of the Free
Software Foundation, said: "With Mono and DotGNU, we hope to provide a
good alternative to all of .NET, one that will respect your freedom, and
your privacy. You will be able to use the facilities of Mono and DotGNU
either with, or without, the Internet, and using servers of your choice."

IANAL, but until very recently, your suspicions were basically correct; company lawyers have their field day with shrink-wrap licenses but they're very very careful not to test the more exotic provisions in court.

That is, until they're safely set up inside a UCITA-adopting state.

Why, you ask? What's this UCITA anyway? Not another acronym. I'm too lazy to write another letter. Trying to keep my phone bill down. And I can never keep my boycotts straight once I get to the store.

From the mouth of the beast...

And on a slightly more ethical tip...

The FSF's writeup

And the CPSR's writeup...

Google will give you more.

Think your EULA's not binding? UCITA gives it all that 100%-All-American Bought and Paid For Congressional Stamp of Approval. Some democracy we have, huh?

-David

Why do people keep modding up this troll?
Ripped off from

Stallman added: "Mono will enable you to run your C# programs on the free GNU/Linux operating system using exclusively free software. With Mono, you will be able to use C# if you wish, without surrendering your freedom to study, share, change, and generally control all the software that you use."

I don't know where AirLace gets the idea that GCJ can't do runtime introspecting. It's been able to do that for a long time.
GCJ is a full-featured Java implementation, including introspection and a full JVM. The main features missing are in the GUI: The AWT implementation is not yet usable. But since Eclipse mostly uses its own SWT GUI widgets, it probably wouldn't take much to get it working with GCJ.