Slashdot Mirror

Not yet, but coming soon to a distribution near you. http://wiki.debian.org/DebTorrent

RMS's post about invariant sections:
http://lists.debian.org/debian-legal/2003/08/msg00807.html
Bushnell's post that got him in trouble:
http://lists.debian.org/debian-legal/2003/09/msg00707.html

Bushnell's email relating to his resignation:
http://softwarelibero.it/pipermail/discussioni/2003-November/008465.html

RMS's post about invariant sections:
http://lists.debian.org/debian-legal/2003/08/msg00807.html
Bushnell's post that got him in trouble:
http://lists.debian.org/debian-legal/2003/09/msg00707.html

Bushnell's email relating to his resignation:
http://softwarelibero.it/pipermail/discussioni/2003-November/008465.html

I remember not even Win95 could copy lots of files... Win98: The same. Win2k: The same. WinXP: The same. 12 years and still the same problem? I really don't remember about Win3.1 or Win286... If ever the Windows code gets open-sourced, lots of programming hackers are going to laugh for years upon seeing the buggy code, I am sure. How come people now have alternative choices and still use a buggy closed-source OS is beyond me. Poor Windows users... (happily posting from Debian GNU/Linux 4.0 amd64 etch + some lenny).

I think one of the most stringent set of license requirements in the community is the Debian Free Software Guidelines. After reading the MS-PL and MS-RL, it seems that it would meet the DFSG. I'm sure there will immenently be debate on the debian-legal list where this will be hashed out in much more depth. If both OSI and Debian accept the license, I'm pretty sure it will be safe to use, modify and distribute software under this license.

-molo

For Debian and Ubuntu, it's pretty easy. Actually, you don't have to worry so much about Ubuntu directly, just get it in Debian and it will ultimately be part of Ubuntu (though it may by in multiverse or universe, rather than main).

To get it in Debian, the first step is to create a Debian package. There are lots of tutorials on how to do that, and it's not too difficult. What will take a little more time is reviewing the Debian policy documentation to be sure that your package installs everything the Debian way. Parallel with that, hop on the debian-mentors mailing list and either find a Debian Developer willing to sign on as maintainer of your package, or to sponsor you to become a Debian Developer yourself, then upload your package to the repository. If you run into any snags with creating your package or understanding the policy issues, debian-mentors will support you there as well.

For Debian and Ubuntu, it's pretty easy. Actually, you don't have to worry so much about Ubuntu directly, just get it in Debian and it will ultimately be part of Ubuntu (though it may by in multiverse or universe, rather than main).

To get it in Debian, the first step is to create a Debian package. There are lots of tutorials on how to do that, and it's not too difficult. What will take a little more time is reviewing the Debian policy documentation to be sure that your package installs everything the Debian way. Parallel with that, hop on the debian-mentors mailing list and either find a Debian Developer willing to sign on as maintainer of your package, or to sponsor you to become a Debian Developer yourself, then upload your package to the repository. If you run into any snags with creating your package or understanding the policy issues, debian-mentors will support you there as well.

Most Linux fanboys are a buch of hypocrites. They would diss Linspire, but then go right ahead and install proprietary Flash and RealPlayer, and use a Windows codecs when available.

Lispire is the thing to give your papa, or granny. Power-users, shut up. Most of you aren't compiling stuff with MLTon anyway. So shut up. Even most of you don't need Debian or FreeBSD. It's just that fixing stuff that's breaking in Leenox distros feels like you're doing Real Work (TM). (Gee, look, I got Debian to install my package without removing the kernel!)

Just put "Linux" in people's mouth. Me, I'm happy they pronounce any word ending in *nix. Later we explain - "actually, that was just a Unix-like OS. Here, take PC-BSD. Give it a try."

It seems to me that it would be worth the trouble to mechanize startup so that each step is isolated from all the others and knows which previous step it's dependent on and waits for only that step, while everything else cruises ahead in parallel.

There is work being done on this already. I can't remember specific links right now (googling turns up some interesting links), but I remember I first heard about it on Planet Debian, an RSS feed collector for Debian developer's blogs; I've found some very interesting things by browsing by there every once and a while. See also init-ng.

how many of us really have the wherewithal to make an architecture jump from x86?

have you considered writing this as an extension to auto-apt?

"Windows XP SP3 build 3205 ... has been made available to testers as a part of the ...Windows Vista SP1 beta program."

God, I love this company!

http://www.debian.org/devel/wnpp/orphaned

Is a good starting place :-)

Whoops, well that is road kill of a different stink. Dumbass me just assumed that the source was out there that it was GPL. I didn't even think of a different license. Oh well, the source is there so you have the ability to look through it and compile it yourself, along with decent peer review too.

TrueCrypt is not licensed under the GPL. It uses its own crummy license which has has serious issues WRT free(dom)ness.

You're free to any part of it I can duplicate.

One day, we'll look back at PC security of today and laugh at the crap one had to go through just to not have your typical PC go down in flames.
...Could be tomorrow if you downloaded an .iso tonight.

In an ideal world would Tux go chimney-to-chimney world round in a single clockcycle and force all linux users to update tzdata at gunpoint?

Sure. This is not an ideal world.

In this non-ideal world the updated version of tzdata was added to etch-volatile at the end of July. That's a full two months anyone who needed it could've done extensive research about how to get it. http://packages.qa.debian.org/t/tzdata/news/20070731T155541Z.html

If you're a single debian etch user in NZ then simply install the update manually. Takes what, half a minute at best?

If you're admin of a lot of etch systems you should either put volatile in your repository list or (I like this better) set up a local repository on your own network so that you can roll out exactly the packages and versions you want.

And for the sake of anyone who does need this package and is patiently waiting. Stop waiting.

http://packages.debian.org/etch-volatile/tzdata/all/download

It's right there.

In an ideal world would Tux go chimney-to-chimney world round in a single clockcycle and force all linux users to update tzdata at gunpoint?

Sure. This is not an ideal world.

In this non-ideal world the updated version of tzdata was added to etch-volatile at the end of July. That's a full two months anyone who needed it could've done extensive research about how to get it. http://packages.qa.debian.org/t/tzdata/news/20070731T155541Z.html

If you're a single debian etch user in NZ then simply install the update manually. Takes what, half a minute at best?

If you're admin of a lot of etch systems you should either put volatile in your repository list or (I like this better) set up a local repository on your own network so that you can roll out exactly the packages and versions you want.

And for the sake of anyone who does need this package and is patiently waiting. Stop waiting.

http://packages.debian.org/etch-volatile/tzdata/all/download

It's right there.

In an ideal world would Tux go chimney-to-chimney world round in a single clockcycle and force all linux users to update tzdata at gunpoint?

Sure. This is not an ideal world.

In this non-ideal world the updated version of tzdata was added to etch-volatile at the end of July. That's a full two months anyone who needed it could've done extensive research about how to get it. http://packages.qa.debian.org/t/tzdata/news/20070731T155541Z.html

If you're a single debian etch user in NZ then simply install the update manually. Takes what, half a minute at best?

If you're admin of a lot of etch systems you should either put volatile in your repository list or (I like this better) set up a local repository on your own network so that you can roll out exactly the packages and versions you want.

And for the sake of anyone who does need this package and is patiently waiting. Stop waiting.

http://packages.debian.org/etch-volatile/tzdata/all/download

It's right there.

[Quote]
Correct me if I am wrong, but the only way to update packages in default Debian install is through http://security.debian.org/ (or when the distro itself is updated).
[/Quote]

You're wrong :-P.

volatile.debian.net exists for non-security updates. For example:

ClamAV needs you to be running a recent version to get the latest version of the defs file. Updating ClamAV isn't a security update (there isn't a security bug with it). This is the sort of update that goes into volatile.

If you run a mail-server and aren't using volatile you probably should!

Correct me if I am wrong, but the only way to update packages in default Debian install is through http://security.debian.org/ (or when the distro itself is updated). Therefore, the mentioned fix should have come into http://security.debian.org./ And Debian should make sure that its next release includes 'volatile' repository by default as well. Thinking that every user and admin will have to edit /etc/apt/sources.list themselves is pure nonsense! This stubborness of Debian team will cost them. With such attitude, it is not going to be long until Debian is completely abandoned and forgotten, and will only be used by a small bunch of engineers that pretend to be politicians.

Wake up, Debian! You lost your voice when your weekly news letter started to come out once a month, when your users turned to Ubuntu for new software, fun & ease of use, and you yourself got into the fingerpointing blame game. Lose your arrogance and start responding to your users and you will still have a chance!

Correct me if I am wrong, but the only way to update packages in default Debian install is through http://security.debian.org/ (or when the distro itself is updated). Therefore, the mentioned fix should have come into http://security.debian.org./ And Debian should make sure that its next release includes 'volatile' repository by default as well. Thinking that every user and admin will have to edit /etc/apt/sources.list themselves is pure nonsense! This stubborness of Debian team will cost them. With such attitude, it is not going to be long until Debian is completely abandoned and forgotten, and will only be used by a small bunch of engineers that pretend to be politicians.

Wake up, Debian! You lost your voice when your weekly news letter started to come out once a month, when your users turned to Ubuntu for new software, fun & ease of use, and you yourself got into the fingerpointing blame game. Lose your arrogance and start responding to your users and you will still have a chance!

Except that the tzdata2006p-1 package was released to stable on Nov 28 - a couple of weeks _after_ the previous release. So it didn't make the release, but they put it into stable anyway. From the 2006 news archive, the 3.1 update occurred Nov 6, with the next one going out in Feb. This set a precedent - timezone data was worth backporting.

I think the patch is in Debian volatile repository, which is Debian's policy to put there any software updates that aren't security bugs but are needed to keep the system working properly. A Debian GNU/Linux user/sysadmin (I am one incidentally) should know about volatile (if not it means that either there is insufficient documentation or the user/sysadmin didn't RTFM). Comparing Debian with Microsoft is wrong, because Microsoft Windows Update is used to update a variety of issues with Windows, not just security bugs. But Debian is usually only focusing on security updates after a stable release is made, it is their policy (whether it's good or bad is another story). The volatile repository was made for non-security important updates, which I think fits nicely with a timezone update. It is important to realise that new Debian users/sysadmins must learn the apt system pretty well, as it is fundamental in managing a Debian system. Debian just follows its own policies here, while still allowing users/sysadmins to get the patch through volatile (and I think also backports), and why this hit Slashdot I really don't know. Of course, this update should be included in the next point release (ie 4.0r2), and perhaps a higher number of volunteers would be helpful here. Are any of you willing to actually help Debian include important bugfixes and updates in next point releases rather than losing your time discussing about non-issues?

So pray explain why they pushed a timezone update for the US changes earlier in the year?

They didn't. They did exactly the same for the US updates as they are doing for the NZ updates. A list of the pushed security updates can be seen here. You'll note it doesn't include tzinfo. Here is the list of packages that have been updated via the 'volatile' distribution. It does include tzinfo, which it seems (if I interpret the versioning system correctly) has been updated 6 times this year.

So pray explain why they pushed a timezone update for the US changes earlier in the year?

They didn't. They did exactly the same for the US updates as they are doing for the NZ updates. A list of the pushed security updates can be seen here. You'll note it doesn't include tzinfo. Here is the list of packages that have been updated via the 'volatile' distribution. It does include tzinfo, which it seems (if I interpret the versioning system correctly) has been updated 6 times this year.

You're misunderstanding. Go to the Debian volatile page to understand the whole picture. In a nutshell, though, when the OP said "keep them functional" (which was a direct quote from the provided link) he did not mean "prevent them from crashing or spamming you with errors or whatever". He meant that there are some packages (like spam filters, for example) that are volatile in the sense that they are constantly changing and by definition incapable of being useful if the version you're running is from 3 years ago. Running a spam filter from 2003 isn't going to be very useful because spammers have shifted tactics. It's not that you can't run that program, or that it's broken — just that it's not functional.

People on Slashdot who always want the latest and the greatest on their desktop often don't understand the impetus behind Debian stable, and lampoon its slow upgrade cycle. But as anyone who has done real admin work will tell you, once you get a working system running, you really want to touch it as little as possible, because updates and upgrades often break things. So most admins stick to security updates and that's that. The truth is, the version of GNU ls from 1994 lists directory contents just as well as the bleeding edge CVS version — there's no good reason to risk screwing up your setup for something so trivial.

But, as people have often noted, other than security issues, there are some packages that simply need updates more frequently than the Debian stable release cycle can accommodate, and so the volatile repository was born. Previously, the Debian devs had to prioritize certain updates (like say, a New Zealand DST time zone update that affects only people on a little island in the south pacific) and push them out as security updates. This was bad because they aren't security updates — no matter how you think about it, a vulnerability in Apache and an update to your spam filter or to the New Zealand timezone data are not in the same league, and serious system administrators appreciate being able to get updates for the former while foregoing the latter.

Debian volatile was expressly designed to deal with exactly this sort of package. The people complaining apparently did not realize that, well, these days, only security updates go into security, and other pressing changes affecting packages in stable go into volatile.

In other words, they didn't understand how Debian works, expected them to do it one way, and were surprised when they didn't — even though if you think about it for two seconds you'll realize that Debian's way is the right way and their's was the god-cursed-stupid way.

Keep your spam filter and timezone updates out of my security updates. I don't want production level systems to get an update unless they need it for security reasons. I know I can trust Debian not to mess with me and that's why they're the only serious Linux distribution out there, in my opinion.

... [Microsoft] charged $4000 for a time zone update for Windows 2000. A server OS. When you can do it for free if you know how. Debian should charge NZers $4000 Canadian (OUCH!), then they would be respected.

The hotfix is for an operating system which is 7 years old! Microsoft still releases free security updates for Win2k, but has a maintenance plan for non-security hotfixes. Unlike Debian, whose stable release in 2000 (Debian 2.2 or "potato", released 8 months after Windows 2k) receives no updates, security or otherwise, nor does the release after it (Debian 3.0 "woody"). Additionally, the bug for the 2005 stable release (Debian 3.1 Sarge) does not have a NZ DST fix yet. The article concerns freshly baked Debian 4.0 "etch" (released 2007) which is the only "stable" Debian which has this NZ DST fix. Apparently the price of free updates for Debian "stable" is an upgrade treadmill!

Of course you can fix the timezone data for Win2k and WinNT for free (try even finding guidance for manually DST tables on systems 7+ years old for Debian). Microsoft tells you how to do it here, so you don't have to go to the parent's random forum link with incomplete or inaccurate information. Microsoft's article is updated with the latest time zone changes, and contains guidance for deploying the updates across an enterprise. The $4000 fix is the prepackaged and supported version which you can simply put into your management server and push to all the machines. Of course, the DST update is free for OSes that were released in the last 5 years!

It's been in volatile for _months_:

http://volatile.debian.org/debian-volatile/pool/volatile/main/t/tzdata/

Lennie

That's why the TZ fix will be included in the next stable update release. Like Sarge was updated,

http://www.us.debian.org/News/2007/20070218

The TZ data was never a security fix. But it was part of the update. I would expect similar for the current TZ fix.

From what I can read, the NZ timezone was changed sometime midyear and the politicians think that all the software will automagically change in a few days? The problem is with the NZ politicians, not Debian.

It's in volatile (where it should be)

The whole FA is a big mis-understanding of what the various repositories are and what they purpose are.

• stable - litteraly means stable, as in mountain rocks. Once a distribution hits this status, it normally shouldn't change a bit.
• non-US - the USA have some pretty wierd laws concerning patents and cryptography. There are a lot of software that can be made available in the USA (because it infringes patent that can only exist in the USA system, or because it is a cryptographic software whose strengh is declared too high and considered as a weapon), but the same software can safely be used everywhere else in the world. non-US contains software that is as imuable as stable, but that is specifically banned in the USA.
• updates or security - as it names implies, standart updates release for stable version of debian, only provide fixes to bugs that could be abused for exploits. All fixes retain the same exact version, only patching the hole (i.e.: firefox 2.0.0.1 isn't upgraded to firefox 2.0.0.6. Instead it's iceweasel 2.0.0.1-1 that is patched to 2.0.0.1-2 the exact same source code, except for the security fix). In the very unlikely case that after 3 fucking years of development in testing state, there is still a bug that prevents a program to start, the corrected version (same version just patched) will appear here.
• volatile - this are packages that can change version, because their functionnality needs it. Virus scanning engine clamav is there for exemple (because to catch new threats, some times the engine it self needs to be updated, not only the signatures). Timezone goes there too (a computer won't be hacked with a bad timetable. therefore it's not in security)
• volatile-sloppy - for non critical upgrades. Gaim/Pidgin goes there for exemple. It's not critical to the function of the computer, but never the less, IM network companies like microsoft regularily changes their protocoles just to break compatibility with 3rd party clients. Thus clients needs to be upgraded to newer versions from time to time. But because newer version MAY break some compatibility with older distribution, older config files, or old user scripts, it is separated from volatile.
• backports - newer version of software, for those who constantly whine because Debian release are 3 years appart. Usually it's package from testing recompiled in stable environment
• testing - This is much closer to what other distribution call a release. It has more up to date packages, but isn't completly bleeding edge, is somewhat stable. This will become the next stable once everyone in debian is happy and decide to definitely freeze it
• vendors, like samba or 3rd parties maintain their own repositories with software compiled against stable, if you like updating your software to latest version.

More information about voltile, at the corresponding debian site.

Debian is quite popular among some admins because of this. You know, once you install debian on a server, that your installation will still get critical security fixes for the next 3-4 years. But nothing else will change a bit. 0% chance that an upgrade may break your configuration file. 0% risks that all the scripts that you manually wrote will suddenly stop functionning because of subtle differences between version 1.8.6.9 and 1.8.6.10 in some obscure software. (which are things that could occasionally happen with other distribution ) NO dependency hell once you start using updated software (like a 3rd party repository targeting a library version 2.0.9, but the distro having updated to 2.0.11. Very rarely it can happen between openSUSE and packman).

But as AC said in this thread, maybe the installation procedure of Debian should give

Ah... found it (and in a link from the FA, as well... go figure). The US DST changes, according to this bug report went into tzdata2006p - which, sure enough, got the changelog got pushed to stable Nov 28.

So that does beg the question - if it's okay to do it for the US, why not NZ?

Ah... found it (and in a link from the FA, as well... go figure). The US DST changes, according to this bug report went into tzdata2006p - which, sure enough, got the changelog got pushed to stable Nov 28.

So that does beg the question - if it's okay to do it for the US, why not NZ?

It all sounds like a shitstorm in a chamber pot to me.

The package sits in volatile for months. Please take your troll elsewhere.

It will go through etch/updates when the new point release will be issued, and we missed the previous window because the bug was open a few days before the last release, and it couldn't make it sorry. So we pushed it in any other place we have access to, namely backports.org and volatile.debian.org (the latter is designed to fulfill updates of volatile packages, _LIKE_ timezone datas). You don't want to use volatile repositories ? Your loss. But stop insulting us. You are the stubborn one.

From http://volatile.debian.org/: "debian-volatile will only contain changes to stable programs that are necessary to keep them functional".

Slashdot got trolled once again with a false story. Nothing unusual, and always deserved, but when it harms Debian's reputation in an area where it used to be at fault but now does the proper thing, it's just irritating.

It's in volatile repository.

Volatile is specificly designed to take into account things like this. It's for updates to packages, like anti-virus software, and similar things that change over time.

Nobody actually reads the fucking articles do they? The guy that posted the article is a troll and selectively took quotes out of context.

What SlashDot says:
"Although a tzdata release that includes New Zealand's recent DST changes (2007f) has been out for some time, Debian are refusing to push the update from testing into the current stable distribution, codenamed Etch, on the basis that 'it's not a security bug.' This means that unless New Zealand sysadmins install the package manually, pull the package from testing, or alter the timezone to 'GMT-13' manually, all systems running Debian Etch in New Zealand currently have the incorrect time, as DST went into effect this morning. As one of the last comments in the bug report says, 'even Microsoft are not this silly.' The final comment (at this writing), from madcoder, says 'The package sits in volatile for months. Please take your troll elsewhere.'"

What is actually in the Bug Report:
----SNIP----
The fix is already in the volatile archive (see
http://volatile.debian.org/ in the etch-proposed-update archive and it
will also appear in the next release of etch. Alternatively you can also
download the new version by hand and use dpkg -i.
----SNIP----

ALSO:
----SNIP----
>>> I would recommend re-opening this bug and upgrading its severity until the fix has been
>>> applied.
>> That won't change anything as it is now out of control of the glibc team.
>>
>
> And these mission-critical updates aren't put into security, why?
>

Because it's not a security bug.
----SNIP----

NO SHIT. It's _not_ a security bug. Why should the Debian Security team be forced to deal with something that is not security? Think about it for a whole two seconds.

The tzdata was updated a long time ago and is in a Debian repository that is specificly setup to deal with changes like this.
The person who filed the bug report doesn't like this and thinks that the package should be in the security fix repository.

It's fucking stupid. It's not a security bug. The package has been fixed for a long time. It doesn't have to be installed manually. It CAN be installed manually.

Get a grip people.

Debra + Ian: http://www.debian.org/intro/about#history

Try Debian 4.0. I found it to be easy to use and install. I did the network installation since I have a broadband connection. One I did not have much success with is Fedora 7, I'm sticking to Fedora Core 6, which is on a par with Debian 4.0 as far as easy of use, and setting it up the way you want.
Debian's network installer is the best, however.

I've just always used chrootuid, since there's a Debian package for it. Made by Wietse.

ftp://ftp.porcupine.org/pub/security/index.html
http://packages.debian.org/chrootuid

Check out http://linux-vserver.org/

If you're using Debian Etch then there are prebuilt kernels with the patches applied. It seems basically the same concept as FreeBSD jails or Solaris Zones to me. I've been using it for a while with great success :)

On Debian, setup is like this:
# apt-get install linux-image-2.6-vserver-686 util-vserver vserver-debiantools
# reboot

You can build a new jail like this:
# vserver NAME build --force -m debootstrap -- -d etch -m http://ftp.debian.org/debian

Then set up a network interface for it according to the docs (put some stuff in /etc/vservers/NAME/interfaces)

Works great :)

Or...you can stop paying $128 every 2 years, avoid the Apple vendor lock in, and use your old machine by running Debian PPC.
http://cdimage.debian.org/debian-cd/4.0_r1/powerpc/iso-cd/debian-40r1-powerpc-netinst.iso

Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources, and in some cases even prohibit the programmer from being able to manage their resources.

Given this comment, I'm pretty sure the only garbage collected language you've used is Java, or perhaps a community language like Python. I assure you that garbage collection is quite efficient in serious languages when compared to manual memory management (see OCaml) if you actually read the GC literature on effective algorithms and not simply assume reference counting or other naive GC scheme is clearly optimal; more importantly, automatic memory management is much safer since there are no leaks.

Heck, even Mono's C# implementation uses half the memory of the Java VM, and Mono still uses conservative GC, not accurate GC! Memory efficient GC'd languages are possible, and profiling your application in such languages to isolate and optimize resource use is entirely possible, and in the end, you have no leaks due to the automatic memory management. You can't say the latter for any C/C++ software.

C/C++ and similar languages, on the other hand, force the programmers to manage their resources.

This what I call "The Grand Misconception". C/C++ does not "force" you to manage resources at all. In fact, the complete lack of this forcing is the result of most bugs with C/C++ programs: leaks, buffer overflows, etc. The C/C++ type systems are simply not powerful enough to reason about resource lifecycles, which means you are free to manage resources, or not, or manage them improperly, at your leisure; sounds great sometimes, and yet it leaves us with software like IE, Firefox, etc., which are generally funtional, but where leaks and security holes are prevalent and likely impossible to entirely eliminate. Any resource leak is an exploitable security hole, period (but not the only source of security holes).

If a language did actually force you to manage resources, then it would produce compile-time errors when you misused a resource, ie. early deallocation, dangling pointers, etc. If you don't understand what that means, then I suggest you read up on more CS literature, specifically linear types, alias types, region types, and region-based memory management (as used in the Cyclone language). These are type systems where resources can be managed more explicitly, but which produce compile-time errors when a resource is misused in some way.

Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources, and in some cases even prohibit the programmer from being able to manage their resources.

Given this comment, I'm pretty sure the only garbage collected language you've used is Java, or perhaps a community language like Python. I assure you that garbage collection is quite efficient in serious languages when compared to manual memory management (see OCaml) if you actually read the GC literature on effective algorithms and not simply assume reference counting or other naive GC scheme is clearly optimal; more importantly, automatic memory management is much safer since there are no leaks.

Heck, even Mono's C# implementation uses half the memory of the Java VM, and Mono still uses conservative GC, not accurate GC! Memory efficient GC'd languages are possible, and profiling your application in such languages to isolate and optimize resource use is entirely possible, and in the end, you have no leaks due to the automatic memory management. You can't say the latter for any C/C++ software.

C/C++ and similar languages, on the other hand, force the programmers to manage their resources.

This what I call "The Grand Misconception". C/C++ does not "force" you to manage resources at all. In fact, the complete lack of this forcing is the result of most bugs with C/C++ programs: leaks, buffer overflows, etc. The C/C++ type systems are simply not powerful enough to reason about resource lifecycles, which means you are free to manage resources, or not, or manage them improperly, at your leisure; sounds great sometimes, and yet it leaves us with software like IE, Firefox, etc., which are generally funtional, but where leaks and security holes are prevalent and likely impossible to entirely eliminate. Any resource leak is an exploitable security hole, period (but not the only source of security holes).

If a language did actually force you to manage resources, then it would produce compile-time errors when you misused a resource, ie. early deallocation, dangling pointers, etc. If you don't understand what that means, then I suggest you read up on more CS literature, specifically linear types, alias types, region types, and region-based memory management (as used in the Cyclone language). These are type systems where resources can be managed more explicitly, but which produce compile-time errors when a resource is misused in some way.

So, first a straw man, and then an ad hominem. Good to see your debating skills are on top form. You might find this set of weightings interesting. Two things are taken into account; the CPU time taken to run the code and the amount of code required to solve each problem, with a 1:2 weighting (concise code more important than fast code). The code complexity is determined by stripping comments and gziping the result. With these weightings, Ruby comes out ahead of two languages: Tcl and Prolog. Since Prolog is a highly domain-specific language (gorgeous for some things, a nightmare for others), and Tcl is a cruel practical joke, this doesn't seem like something to be proud of.

Next, he exposes his naïveté by calling PHP fast,

Compared to ruby it is and with an opcode cache PHP performs much better. The bottleneck for a web app is always going to be database queries.

So, we have a slow language, with ugly syntax. The ugly syntax is subjective, so we'll overlook it for now. We have a slow Smalltalk, but maybe the framework makes up for it. Looking at Ruby on Rails, it seems like a cheap clone of the old NeXT WebObjects (cloned as GNUstepWeb and SOPE, uses Objective-C, which is typically faster than Smalltalk), and so far behind something like Seaside it's not even funny.

So, why do people use Ruby? Or is it like Java, as Guy Steele said: