Slashdot Mirror

Geez, maybe you should pay attention to what you are answering. As I said already, most people do not care about development of software and totally don't care about software development tools.

Those who do, can quite easily work under MS Windows by using Free Software tools. GCC - go down the list and you will see that you can get yourself a build that works on MS Windows.

Here is a PHP installer for Windows.

Here is a JDK installation for windows from Sun.

Here is a bunch of Free apps that will run under Java on any platform Apache

Here is a nice development tool for you - Eclipse.

Here is cygwin, in case you want your vi and other *nix tools under MS Windows.

I can give you thousands more examples. A whole bunch of interpreted languages, native compilers, free dev tools, you name it. It all works under Windows. You are spreading the FUD.

Now, as I said, the argument that GNU/Linux costs less works much better for the PCs sold to lower-class people, if it means they can actually afford the box.

If you are a middle-class individual, who can afford the box even if it is whatever X dollars more expensive, you are much better off with a Windows box. The chances are you will want to run MS Windows software and if you cannot then what good is the box?

Anyone at all can download a Free OS, once you have some OS installed on some box.

BSD *is* a free software license, according to the FSF...

If you want a simple, permissive non-copyleft free software license, the modified BSD license is a reasonable choice

You probablary meant to say "copyleft" or "gpl-like".

It's right in the GPL FAQ

If the version has been released elsewhere, then the thief probably does have the right to make copies and redistribute them under the GPL, but if he is imprisoned for stealing the CD he may have to wait until his release before doing so.

If the version in question is unpublished and considered by a company to be its trade secret, then publishing it may be a violation of trade secret law, depending on other circumstances. The GPL does not change that. If the company tried to release its version and still treat it as a trade secret, that would violate the GPL, but if the company hasn't released this version, no such violation has occurred.

I used to publish documents under teh GNU GDL, the GPL for text http://www.gnu.org/licenses/fdl-howto.html - but after actually reading it I found it had some very strange points that kind of limits "fair use" (freedom) as I instended. Now I use Creative Commons 2.0, a license I find more suited for the modern Internet.

However, having said this, it's still quite understandable for people to not want Linux development being tied to a closed-source product with nasty gotchas in it's free license. That's not whining in the least.

The problem is that people who whined about BK being propietary should have shut their mouth up, but they didn't. When Linus switched to BK, he made clear that he would NOT force to anyone to use BK, and that's how it has been: Linux kernel.org releases are released in GNU diff format, so everybody can code and contribute. The one reason why all^Wmost of the kernel developers use BK is because they aren't stupid, BK is a great tool and can save hours of work, and it lets them to work easier between those who use BK. When someone wants to get a patch to get merged they also made the GNU diff format patch available, and even if they didn't, bkbits.net provides you a link to get a GNU diff patch for every changeset out there. Those who claim that "anyone who wants to closely track patches to Linux can only do it by installing that non-free program" to develop the kernel are just wrong because you have access to the latest kernel changes without installing a non-free tool. -mm and -ac tree are maintained using open tools, so I don't see where is BK being "required".

The one reason why people whine is because they want to have the advantages of BK, but without using a propietary tool. That's not possible, there's not a OSS tool comparable to BK, subversion arch and friends are not even close. Everybody agrees that having such tool would be great (Linus even tried to convince Larry to release BK under a open license) but there's not one.

IMHO is just like when RMS had to use propietary tools to start developing GNU - Linux developers just use BK because using a OSS SCM would mean the linux kernel development would slow down a lot, and that's not good (and again, if you are going to propose to use subversion, arch, etc, it probably means that you do not understand the frenetic kernel development needs and the power of BK)

There are so much real open alternatives like subversion, arch and (my personal favourite) darcs - just to name a few. Why bother with bitkeeper?

ISTM you feel you'd get some kind of kudos from the label `open source', but don't want to actually do what earns that kudos (letting go to some small extent of your creation).

Indeed, according to the FSF, that's a major reason the open source movement exists:

Over the years, many companies have contributed to free software development. Some of these companies primarily developed non-free software, but the two activities were separate; thus, we could ignore their non-free products, and work with them on free software projects. Then we could honestly thank them afterward for their free software contributions, without talking about the rest of what they did.

We cannot do the same with these new companies, because they won't let us. These companies actively invite the public to lump all their activities together; they want us to regard their non-free software as favorably as we would regard a real contribution, although it is not one. They present themselves as ``open source companies,'' hoping that we will get a warm fuzzy feeling about them, and that we will be fuzzy-minded in applying it.

This manipulative practice would be no less harmful if it were done using the term ``free software.'' But companies do not seem to use the term ``free software'' that way; perhaps its association with idealism makes it seem unsuitable. The term ``open source'' opened the door for this.

a detailed explanation of why you should vow to never buy anything that implements this. http://www.gnu.org/philosophy/can-you-trust.html

The Free Software Foundation's article entitled Can you trust your computer?

...is the first Google hit for "treacherous" :-)

And for those who are going "huh, what?" the short version is this: So called 'Trusted Computing' is the only way that companies that want to prevent you from accessing data on your own computer can make it happen -- DVDs that you can't screen capture or skip the ads in, music files you can't save to your old music player, text data that you can't export to your screen reader, etc.

Although unlikely, this could conceivably also be used to prevent you from running whatever OS or software you want on a particular PC.

As such, Richard Stallman, in his essay (which you should read, above), has chosen to refer to it as "Treacherous computing", kind of the geeks own version of the "Santorum" campaign.

It's time to push for an hard for a free bios. You can help if you
can figure out how to install a new bios on a computer, especially a
laptop. I don't know why we can put linux on an xbox but nobody can
get a free bios on a laptop.

Stick to AMD machines, avoid Intel and IBM. Heh, IBM. We talk like
they're our allies but they're pushing patents and treacherous
computing. They're a _much_ bigger threat than SCO ever was.

If you haven't yet read stallman's dystopian short story The Right To Read,
this might be a good time.

Treacherous computing is the reason I'm a GNU+linux user.

Can you trust your computer?

Make sure to read this:
The Right To Read by RMS.

Just remember, folks: "Trusted computing" is an Orwellian phrase that actually means your computer won't trust you. So if you want your computer to have to ability to say to you, "Sorry, I won't play that MP3 file" or "Sorry, that movie is not authorized for this PC," well step right up. Barnum & Co. -- er, sorry, I mean major PC hardware companies have some new machines to sell to you.

Off Topic? The question is "Do you think Sun's Java will ever become open source?"

Answer: It may not be from Sun, but there is always gcc -> http://gcc.gnu.org/

Extremely relevant point here, folks. Did Daimou include the license agreement with the derivitive work?

That *is* an extremely relevant and good point. See also the GNU page on Violations of the GPL, LGPL, and GFDL. The first question of all is "Does the distribution contain a copy of the License?" I'd be curious to hear if Daimaou had been conscientiously attaching the GPL to each iteration of the code. It seems that he should have been. It doesn't change the fact that the company's behavior is a violation of the GPL, and -- from what it sounds like, it may be that the company would not have acted any differently even if he had. But it does seem to be worth keeping it in mind if one is ever in a similar situation.

The GNU page also lists an email for reporting possible violations -- if the copyright holder is the FSF. In this case, it isn't (unless developerWorks and ActiveState turned their code over to the FSF =)

So Daimaou needs to contact those companies, and not the FSF.

I also want to second the post, a bit further down on this page (at the time of this writing, anyway), titled The contract may not be enforcable. Faced with a similar "we own your brain" contract several years ago, I declined to accept those terms. But I was so incensed by it that I talked about it with many people. And was told by some/many of them that these contracts are generally considered to be unenforceable in "most states." With the caveat, though, that things like that are very much subject to change depending on court cases establishing new precedents.

From the preamble (with emphasis added):

Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

And, section 4:

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

If the company has already distributed MyApp, but has not included the proper notices required by the GPL, then under section 4 of the GPL, the company has forfeited any rights to distribute GPLFile.c ever. In this case, any future attempt to distribute GPLFile.c (in binary or source form), or anything that includes it, violates copyright law, because the rights that might have been granted under the GPL no longer apply to them.

Once you forfeit your rights under the GPL, you cannot regain them (unilaterally), and you are not even allowed to distribute the original source code.

In practice, we typically see companies "fixing" their GPL violations, by ignoring section 4, meeting all the other requirements, and pretending that no violation ever happened. So far, copyright holders have tolerated this, because it serves their purposes, but there's no reason why they must. I can imagine a scenario where "the company" we're talking about is actually a fierce competitor of IBM, and where IBM gets a permanent injunction against this company to prevent them from distributing MyApp, whether under the GPL or not.

Some people should really take the GPL much more seriously. It is not a toy, and you can't expect to wait until you get caught violating it before you come into compliance.

It is more complicated than that. Look at section 5 of the GPL: Modifications of GPLed programs are an explicite expression of accepting the terms of the license. The instant the company stops to accept the GPL, it also loses the right to modify the code, even if they only use it internally. But the only way to infringe on the GPL is to try to distribute the original or modifications hereof with a license incompatible to the GPL.

So the situation is this: Everything is fine with GPLed software. No restrictions are in place as long as you don't start to distribute the original or derivative works of the original. The instant you start to distribute the original or any derivative works without a GPL compatible license, you lose all rights to the original, including the right to use the original and to modify it.

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 thank you 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. It's like Ada all over again! 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. 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^H Perl is dying.

When I started working for my employer several years ago I signed an IP agreement that states anything I think while working for them is theirs, as well as anything I've ever thought in the past if it enters their building; dumb, but I needed a job.

When I start a job that wants such an agreement, I always add a rider that anything I do in my own time, on my own equipment, is mine, not theirs. The FSF also requires a copyright assignment from your employer or university before accepting changes, to prevent this sort of problem.

In some states (such as California), it's a moot issue: anything you do on your own time, on your own equipment, is yours. Period. The employer can't usurp that with a blanket statement. (I'm not a lawyer, and this isn't legal advice.) So you may have an out through your state law.

This makes no sense at all. The work he added IS inherently derivative of the GPL when he starts with GPL code. That's what derivative means.

It depends exactly how he derived. If he just linked a few new files to it then I don't see how that is.

As I just posted above (accidentally as an AC, bah) he's still the owner of the changes from a copyright point of view and free to relicence them as he sees fit. The GPL FAQ mentions that you *can* separate public domain code from GPL code and use it as public domain which seems applicable here - after all, he has full rights to his own code c.f. public domain. The FAQ also says you can release your own code both GPL and not free.

This makes no sense at all. The work he added IS inherently derivative of the GPL when he starts with GPL code. That's what derivative means.

It depends exactly how he derived. If he just linked a few new files to it then I don't see how that is.

As I just posted above (accidentally as an AC, bah) he's still the owner of the changes from a copyright point of view and free to relicence them as he sees fit. The GPL FAQ mentions that you *can* separate public domain code from GPL code and use it as public domain which seems applicable here - after all, he has full rights to his own code c.f. public domain. The FAQ also says you can release your own code both GPL and not free.

From the GPL Preamble:
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

• You can separate public domain code from GPL code and use it as public domain
• You can release your own code both GPL and not free

• You can separate public domain code from GPL code and use it as public domain
• You can release your own code both GPL and not free

• You can separate public domain code from GPL code and use it as public domain
• You can release your own code both GPL and not free

A) How in the hell can they read zeroes? Perhaps if you *deleted* the data (i.e. on an OS level) they can read it, but I doubt that if you filled the drive with zeros they could do anything.

In short, there are no "ones" or "zeroes" on your hard drive, but only certain signals that represent them. Somewhat oversimplifying, when you write 1 over 1, the value is slightly larger than 1 written over 0.

It doesn't matter for the hard drive as long as both are well over certain threshold and will never get confused with 0. But when you subtract a perfect 1 from all of the "ones" on the hard drive (and leave the "zeroes" alone), then you will get a weak signal which is a shadow of the previous data. Amplify it and you have more or less the same signal that was there before the overwriting.

You can do it once more and get the data before that, and repeat it until you hit the limitation of your equipment sensitivity and the noise of the signal itself, but recovering few generations of data is usually possible, and recovering the previous data is trivial, especially when you deleted it with zeroes, so you don't even have to bother with removing the 1s.

That is why I always run:

shred -vz /dev/hda

before I stop using any hard drive.

B) Assuming they can, destroy it in some other way.

From info shred:

The best way to remove something irretrievably is to destroy the media it's on with acid, melt it down, or the like. For cheap removable media like floppy disks, this is the preferred method. However, hard drives are expensive and hard to melt, so the `shred' utility tries to achieve a similar effect non-destructively. This uses many overwrite passes, with the data patterns chosen to maximize the damage they do to the old data. [...]

Shred is available in GNU fileutils.

See also Secure Deletion of Data from Magnetic and Solid-State Memory paper by Peter Gutmann, first published in the Sixth USENIX Security Symposium Proceedings, San Jose, California, July 22-25, 1996.

Abstract: With the use of increasingly sophisticated encryption systems, an attacker wishing to gain access to sensitive data is forced to look elsewhere for information. One avenue of attack is the recovery of supposedly erased data from magnetic media or random-access memory. This paper covers some of the methods available to recover erased data and presents schemes to make this recovery significantly more difficult. [emphasis added]

Introduction: [...] In the 1980's some work was done on the recovery of erased data from magnetic media, but to date the main source of information is government standards covering the destruction of data. There are two main problems with these official guidelines for sanitizing media. The first is that they are often somewhat old and may predate newer techniques for both recording data on the media and for recovering the recorded data. For example most of the current guidelines on sanitizing magnetic media predate the early-90's jump in recording densities, the adoption of sophisticated channel coding techniques such as PRML, the use of magnetic force microscopy for the analysis of magnetic media, and recent studies of certain properties of magnetic media recording such as the behaviour of erase bands. The second problem with official data destruction standards is that the information in them may be partially inaccurate in an attempt to fool opposing intelligence agencies (which is probably why a great many guidelines on sanitizing media are classified). By deliberately under-stating the requirements for media sanitization in publicly-available guides, intelligence agencies can preser

This is rather unfortunate as both projects just advance slowly as they suffer a lack of developpers.

Marcel

I as the content creator

Which parses as "I as the happy god". A better word for one who creates works of authorship is the term the law uses: "I as the author".

In general, regressions where the compiler generates incorrect code, or refuses to compile a valid program, will be considered to be sufficiently severe to block the release, unless there are substantial mitigating factors.

#include <iostream>

#include <stdio.h>

And if you are using templates, you are actually using a compile time language, which obviously will slow compilation down.

But they do claim C++ compilation is much faster with 4.0:

When compiling without optimizations (-O0), the C++ frontend is much faster than in any previous versions of GCC. Independent testers have measured speed-ups up to 25% in real-world production code, compared to the 3.4 family (which was already the fastest version to date). Upgrading from older versions might show even bigger improvements.

It's freedom for you to make your own choice about wether you wish to have your icons included in the distribution [...]

Actually, it's a power when you deciding whether others can distribute copies of your digital work; that's licensing, telling others what they are allowed to do with the covered work. It would be a freedom if you were deciding for yourself whether to incorporate the work in something of yours. It's ironic that you bring up RMS later on in your post, because he reminds us that the difference between power and freedom hinges on who's affected -- "Freedom is being able to make decisions that affect mainly you. Power is being able to make decisions that affect others more than you. If we confuse power with freedom, we will fail to uphold real freedom.". This means that licensing anything is a power. Freedom means making a decision whose outcome chiefly affects you.

I think the CC is the best step forward for licensing in general. Three clicks and you have a human readable license- both clear and concise and in standard legalese. RMS might have founded GNU and the FSF but Lessig perfected it.

I think that CC does us all a great service as well, but I think that the FSF and CC's work are complimentary and they serve different ends. RMS and Lessig aren't working on licensing the same kinds of works, for example -- RMS' licenses are for computer software and documentation, the Creative Commons licenses are not intended for licensing computer software.

And guess what...

Win4lin already is sponsoring QEMU, and their latest release is based on it.

I have to keep a copyright notice that attributes the code to someone else?

No. You need to keep the notice, but it doesn't imply they hold copyright to the full file.

The GPL tells you what you're allowed to do and what your obligations are, it doesn't tell you how to do this in practice. Does the FSF have documentation on this? I haven't seen it.

The FSF requires detailed changelogs for their own projects. See the GNU coding standards (section 6.8) for more information. You can list all contributors to a file as copyright holders, and people can use the changelog or CVS history if they want details.

The situation with the GPL is precisely analogous to the situation with downloaded music. (Most) music copyright owners expect a payment of some kind in exchange for their providing you with music. Creators of GPL code also expect payment. The only difference is that the music owners expect payment in the form of money, while GPL code owners expect payment in the form of more GPL code. In both cases, you legally have no right to distribute or use the music or code unless you make the appropriate payment - it's just that the terms of payment are different. In both cases, you have the choice not to accept the terms imposed by the owner of the work, by choosing not to use their work (and finding e.g. an independent artist who allows free downloads, or software that is distributed under a BSD or MIT license).

You are free to use GPL libraries in your proprietary code without releasing your code, and to sell your closed code.

Before you call "bullshit", you might want to check your facts: the GPL in fact does not allow this (read par. 2). You're probably confused with the LGPL, which does.

You are free to use GPL libraries in your proprietary code without releasing your code, and to sell your closed code.

Before you call "bullshit", you might want to check your facts: the GPL in fact does not allow this (read par. 2). You're probably confused with the LGPL, which does.

RTFLFAQ and then maybe you'll have enough sense that I'll want to argue with you.

Good thing you're not. We don't need any more ignorant developers.

Its not about passing around source code. GPL forces me to make any code that's linked with it to be GPL as well. Even plugins written for a program, if GPL'ed require the entire program to be GPL'ed. That's a totally unnecessary condition. I'd rather choose BSD or CPL which ask that you pass around source code but aren't thoughtlessly viral.

C99 status page.

But there's only finite resource, of course. You want some obscure feature fixed, why don't you fix it?

PR8234. Looks like it's been closed as not-a-bug.

Long awaited significant improvement on symbols visibility. Saves RAM, saves disk, and as a consequence, allows to save link and load time. -- "La simplicité fait l'élégance"

If you dig a bit more from the above link you find this .

Which in short shows that execution time is exactly where it was a year ago. I can understand it's an overall test which does not take into account specifics, but it also shows that "entire realm of open-source software could get a performance boost" will not going to happen (makes me think that that "could" is there on purpose).

Another clue is that the article begins with "software is built with GCC, a compiler that converts a program's source code--the commands written by humans in high-level languages such as C--into the binary instructions a computer understands". First reaction: "Doh!, i knew that", and at this point it hits me, today is Monday and as you know magazines (online or not) must publish articles to survive.

What's a bit more disappointing that old-trusty /. swallows the bait, if you dare to check gcc website you'll notice that there are no changes as there are no news (real people are actually working and update it when job is done).

Just thought I would point out that Phil is one of the people who have been in charge of the libstdc++ (GNU Standard C++ Library) for a long time. I realise that no one is used to actual subject authorities on slashdot.

There are actually quite a few clean-room Java implementations. The GNU Classpath homepage lists 14 Java VMs that use the Classpath clean-room implementation of the Java class libraries.

For the record, Classpath is 99.79% function complete relative to JDK 1.1 according to the comparison linked from the home page. The numbers drop off with JDK 1.2. Some bits of Swing are missing and most of the org.omg.corba hierarchy is excluded for reasons to do with the OMG's copyright notice.

There are actually quite a few clean-room Java implementations. The GNU Classpath homepage lists 14 Java VMs that use the Classpath clean-room implementation of the Java class libraries.

For the record, Classpath is 99.79% function complete relative to JDK 1.1 according to the comparison linked from the home page. The numbers drop off with JDK 1.2. Some bits of Swing are missing and most of the org.omg.corba hierarchy is excluded for reasons to do with the OMG's copyright notice.

GCC is an incredibly versatile compiler, with frontends for C, C++, Java, Ada and Fortran provided with the basic install. 3rd party extensions include (but are probably not limited to) Pascal, D, PL/I(!!) and I'm pretty sure there are Cobol frontends, too.

The list of other front ends for GCC also include Cobol, Mercury, Modula-2, FLIM, Shakespeare, and GHDL. Note that all are in different states of development.

According to the GCC Development Plan, the 4.0 branch was cut on Feb. 25. On the gcc list, they were talking about making a release appox. 3 months after that (IIRC), but it all depends on how the bug fixing goes.

I realize that things have to change, but I wish that they would not break compat between versions quite so often...

Have you tried maintaining a compiler used in as many situations as GCC? (If not, you should try, before making complaints like this. It's an educational experience.)

We added a "select ABI version" to the C++ front-end in the 3.x series. If you need bug-for-bug compatability, you can have it.

I'd really like to be able to take a binary between versions, and it just work.

Wanna know when this is gonna happen? Sooner, if you help.

"GCC 4.0 also introduces a security feature called Mudflap, which adds extra features to the compiled program that check for a class of vulnerabilities called buffer overruns, Mitchell said. Mudflap slows a program's performance, so it's expected to be used chiefly in test versions, then switched off for finished products." - from the article

I really love this feature, it will probably cut down on a great deal of problems. My only concern is that some devs will think running it all the time is OK (read: "Mudflap slows a program's performance"), so hopefully that's not the case.

More detailed information on the mudflap system can be found here.

is that they're busy working away (especially Thomas Fitzsimons) on GNU Classpath to make sure that with that and gcj there's a full Free/Libre java environment