Slashdot Mirror

Yes - please give credit to where credit is due.

Debian ARM port

My solution is:

$ wget http://cdimage.debian.org/debian-cd/6.0.6/amd64/iso-cd/debian-6.0.6-amd64-netinst.iso

Ubuntu has served me well in the past, but I find it's easier to install just what I want in Debian (and I know exactly what I'm getting) than trying to remove all of the extra stuff in Ubuntu these days.

[...] The BSDs long ago lost relevance. Pretty much there is not a thing that they do better than Linux and there is a lot that they do not do that Linux can do. [...]

Linux will always be shit because of the license.

FreeBSD is a dream UNIX system for anyone who doesn't drink the GPL kool-aid, especially with the transition from GCC to Clang. All the best server-side technologies (Node.js, Nginx, Redis, PostgreSQL, etc) are permissively licensed, and BSD constitutes the OS of that new stack. And, if you use (jailed) Opera (which doesn't require "half of gnome" in dependencies, the way Chromium does), you can have a fully functional HTML5 client system without a drop of GPL!

I also find FreeBSD to be a very stable system. Many times I've had a Linux system fail to start because I installed something bad in Synaptic (or for an undetermined cause), but the FreeBSD base system is bulletproof. It forces you to learn a few things in the beginning (as do the best Linux distros, like Gentoo and Arch), but after that it's very easy. Building from the FreeBSD ports tree always "just works", which isn't the case on Gentoo. Plus pretty much all Linux distros are bloated - for example, can you name one that doesn't absolutely mandate perl?

And, regarding the acknowledged Linux performance advantage (especially in fs) - DragonFly BSD is starting to catchup!

It is painfuil to install [...]

To each his own. I can get OpenBSD installed, pkg_add everything I need, untar everything I need to untar, etc - all in the time it takes a popular Linux distro installer just to load Gnome3 on its massively bloated LiveCD!

One major installation convenience weakness that BSD's still have is the difficulty of dealing with partitions. If you're switching between Windows and Linux, you can use something like gparted to shrink your old partition, create a new one, move files over, delete old partition, and then resize the new to fill the disk. If switching to/from or between BSDs (and not using multiple HAMMER volumes), then you're gonna have to back up to another drive... With cheap USB3 HDDs that's no longer as much of an issue though, and keeping such a drive for backup is a good idea in any case.

[...] and the hardware support is worse than Windows.

All UNIXen, including Linux, have inferior desktop hardware support to Windows. No wonder - desktop device manufacturers must place the needs of the >90% first!

BSD's (if not one then another) are pretty good at keeping up with Linux on server hardware that most people use. Sometimes Linux will include a proprietary BLOB to support a device, while the OpenBSD people will make the effort of writing a fully open source driver.

I cant see a a strength to it.

BSD is for people who care about freedom, first and foremost. It has some technical merits (which I hope will grow over time, as more and more people understand the downsides of GPL, switch to a BSD OS, and contribute), but that comes secondary.

--libman

...and for completeness:

http://packages.debian.org/wheezy/reiser4progs

  The following utilities to manage Reiser4 filesystems are provided:

    - debugfs.reiser4
  *** - fsck.reiser4
    - measurefs.reiser4
    - mkfs.reiser4

You're bang-on. Eric Seigne has a history of spamming his software in inappropriate forums, e.g.:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321776

If you want, you can always donate $$$ directly to Debian and some associated free software like PostgreSQL or FFmpeg. These donations are not used to pay for developer time. They are generally used to reimburse some of the travel costs associated with things like Debconf for the poorer developers, hardware costs for developer machines (something more recent) etc.

http://www.spi-inc.org/donations/

Debian is just one of the members of SPI. There are other software that benefits too,

http://www.spi-inc.org/projects/

And if you are suspicious that SPI is not associated with Debian, just look at Debian's donations page and be happy.

http://www.debian.org/donations

Cheers!
Anonymous Debian Dev.

PS. $$$ is not a big problem for Debian (as everything is either sponsored or volunteered), but it is always welcome.

I would like to counter that point with a reference to the Debian Manifesto. It was published in 1994, and Debian, in addition to becoming one of the most popular distributions by itself, came to form the basis behind products like Ubuntu, Mint, Nokia Maemo, Knoppix and Mepis. So for them it seems to have worked.

I think that we are talking about two different things:

If you use the Free AMD/ATI graphics drivers, you get only the most basic functions unless you provide a proprietary firmware blob. (debian package containing those firmware blobs, among others).

For those device firmwares, the entire "RADEON" directory, covering all supported models(list is in the debian package, I won't clutter this post) is 260k across 41 different firmware files.

As you note, though, fglrx and Nvidia's equivalent modules(plus all the non-kernel stuff that goes into X or elsewhere) is a comparatively gigantic mass, much of which is running on the host CPU and in host memory.

I was referring only to the firmware required to make the free drivers work, which is a nasty surprise the first time you see the message on startup; but does not appear to do what the proprietary drivers do.

There's a lot of reasons to switch distros. Everyone usually finds one that fits their way of thinking after two or three. People also find that the different distros work better at different tasks - you don't (generally) use Ubuntu for servers, for instance.

As far as what I run on "my" computer, it hasn't changed much: Slackware -> Debian unstable. I knew Slackware inside and out (back in the 3.x days) and now I know Debian very well (you have to, if you run unstable). I've hit a comfort zone, and I'm unlikely to change.

I switched from Slackware to Debian because Slackware was very, very far behind on switching from the libc5 C library to glibc (the second major change in Linux, the first being the switch to ELF executable format). A lot of software was being written that didn't work with the old libc5, and Pat (the maintainer of Slackware) was being stubborn on the point. He had his reasons, but I wanted new software, so I switched.

I tried Corel Linux back when it came out. That lasted about two days. It didn't live up to its promises, and when I found myself replacing the Corel repositories with Debian repositories, I knew it was in vain (BTW, doing apt-get update && apt-get upgrade from Corel to Debian is... interesting. It worked, after a lot of fixing, but I finally wiped and reinstalled Debian). It's just as well - there was only the one version of Corel Linux.

I've had to use Red Hat (not Enterprise, but old school Red Hat Linux) on a few occasions for work-related reasons. This was back in the RPM dependency hell days, and it turned me off of any distro that doesn't maintain a decently large package repository. I used Fedora Core 4 and found it to be just as bad. Same goes for Mandrake (before they became Mandriva - I had friends who ran that because it was "user friendly" - I did not find it so. It might be better now, of course.

I've used Gentoo for shits and giggles on a server I run. I was just curious about it. I've since replaced it with OpenBSD because a) I didn't have the time to learn to admin it properly and b) compiling every package in the system on an Intel Atom chip is painful. (I already knew how to admin OpenBSD.) I liked Gentoo and if I ever replaced Debian as my main distro, it would be to go to Gentoo. I just don't have the time to learn a new system anymore.

I've done LFS. I highly recommend it to anyone who wants to learn more about the underpinnings of Linux. It reminded me a lot of my Slackware days, back when you had to compile everything.

Ubuntu works, and I've run it on a few machines, but doesn't fit into my way of doing things. I like to customize my system a lot, and I like to log in as root when I'm doing admin stuff. You can do that with Ubuntu, but it's just easier with Debian.

Of course, there's the BSDs and Solaris as well, and these days I mostly do server stuff on OpenBSD (or FreeBSD if it's a fileserver). The BSDs make excellent servers and don't feel as "hacked together" as Linux does. I wouldn't use one as my main system, but if I had a technical job again I wouldn't mind a FreeBSD desktop.

So the rite of passage isn't to find the most obscure distro, but to find the distro that suits both you and your use case best. Experimentation never hurts, and you can learn a lot from running different distros.

How would you know which md5 hash was correct?

We could reinvent the wheel, but (as usual) the Debian wizards figured it all out years ago, in this case, they solved the problem in 2003.

You make a big list of valid hashes, GPG sign the list with a well known key that is changed every couple years or so (for a good time see Debian package named debian-keyring), and publish it.

For a good time on a Debian box go to /var/lib/apt/lists and look at a packages file. Assuming you're using wheezy/amd64 the system won't let you install the latest 0ad package (wtf that package is) version 0r11863-2 unless the md5 hash of that package is some big ole number ending in 79eb. Also sha1 and sha256 hashes.

For a good time see

http://wiki.debian.org/SecureApt

I can hand you a questionable looking flash drive with debian packages on it and if the multiple signed hashes match Debian's official gpg signed hash list you can trust my binaries... I can't inject something extra without Fing up at least one of the three hashs.

Or, just go ahead and reinvent the wheel... thats a Security Best Practices that never leads to problems, rock on with your NIH self man!

Because it adds nothing but another layer of kruft to fail. Yes, I could jump through the hoops and overcome 15 years of habit to no good end,

Editing a different config file from the one you are used to is not "jumping through hoops."

or I could just sudo apt-get uninstall resolvconf every time, and after every upgrade, just in case it tries to put it back again (and it has, at times).

That, on the other hand, is. Why not just take the most painless route to get what you want? Seriously, it's not that big of deal. There have been tons of similar changes to the Debian userland over the years (pam.d, update-rc.d, modprobe.d, ...). All of them entail moving config files and using scripts or includes to keep master copies up to date. Yes, it might be frustrating to find something you already know has been changed, but it usually takes only about 5 minutes to get up to speed with the new setup.

There is a pretty good rationale for resolvconf on the developer website, if you actually really care about the why.

If you don't like the ads or the commercialism or anything else about Ubuntu, it's a rather minor change to go back to Debian, upon which Ubuntu was originally based. Otherwise, Shuttleworth et al. are free to do what they want, and if you don't like it, well, it's not like you don't have plenty of other choices. In the meantime, give the guy a little credit for massively popularizing and attempting to commercialize a GNU/Linux distro. Because in the long run, that's better for your other choices, too, and in this case, it's really more his own pocketbook than anything that gets hurt when he pisses off his customers. Or not, as the case may be.

Testers should do the testing.

Packagers should do the packaging.

Sysadmins should do installations.

Requiring devopers to know everything in the Debian Policy manual would be too much.

Anything that's in a Debian release has already passed by these issues. That's a lot of disparate architectures. And that's 29K separate software packages.

if you want a 800 number to call and yell at because your Linux computer is not working you could go with any of a number of commercial distro's (redhat, suse,oracle) or any of a number of other firms that will provide support for non commercial distros (canonical). In fact debain keeps a page devoted to paid consultancy firms around the world that will let you scream at them for a set rate $ per hour. http://www.debian.org/consultants/

Well, it's more easy than this. If you have a "non-commercial use" license, then it's not free software. Remember we have the following freedom (nothing new):
0- Use
1- Studdy and modify
2- Redistribute and share
3- Redistribute modified copies

In the case of non-commercial clause, you loose freedom 2 and 3. In Debian, we all agree to the DFSG: Debian Free Software Guidelines: http://www.debian.org/social_contract which clearly specify that we shouldn't "Discrimination Against Persons or Groups". Such license with a non-commercial clause is discriminating for the freedom 2 and 3 of RMS. We consider this type of license as non-free. Full stop!

In the case of Debian, i386 actually means the 486 and later, if you believe their release notes:
http://www.debian.org/releases/stable/i386/ch02s01.html.en#id583669

I can vouch that you can boot the latest stable release on a Socket 5 Pentium.

There is a big difference between ia32-libs and true multiarch: http://wiki.debian.org/Multiarch/

Although Debian and the chart refer to AMD64, it's really generic x86 64-bit support, not AMD-specific. I.e. even though there are differences between AMD 64 and Intel 64, Debian AMD64 will run on both. It would have been clearer had it been named x86-64, and indeed it used to be until it was changed with some tortured logic and desire to give AMD credit for being first with 64-bit extensions rather than have clarity of names and purpose.

Wait...Linux comes with support as well...you just have to pay for it.

http://www.debian.org/consultants/

$5K would keep me in doritos and cheetos for awhile.

...except that Debian didn't actually make XFCE the default (at least not yet) but that fact was missed by most bloggers and their readers. Source: http://packages.qa.debian.org/tasksel

Try this obscure distribution, forgotten these days. It's reliable and you can set it up as you like.

http://www.debian.org/

Scala does indeed have some of what I want...but some number of those features would require VM support to really properly put in place. Without VM support, you could perhaps emulate some of them at the language library level, but you're not going to get the true performance that you would have if the VM were intelligently doing many of the optimizations at a lower level. And I don't think many of those things will end up in the JVM b/c Java's too beholden to backwards compatibility...and since the primary language won't ever support those features there's little motivation to add extra complexity to the VM to support them. I do think the JVM would make a reasonable starting point...people have put a lot of work into developing a number of features which would continue to be very important for the next generation language, and if some of that work can be reused, it would certianly help jumpstart such a project. I do think there's not much point without VM support. A next generation language isn't going to be viable if it exposes nice features but they are slow/expensive. And that, I think, is one big reason why uptake on Scala hasn't been better than it has. I'd have dig around to find it again, but last I saw, there were several significant benchmarks for which Scala performed much slower than Java due to aspects to how the language is designed. Google's little paper notwithstanding, most benchmarks I could find in just looking around (such as the Computer Language Benchmarks Game http://shootout.alioth.debian.org/ ) have Scala coming in a bit behind Java...but well behind it on the high end. I think the next paradigm...it will have to offer more than Scala does, and do it with top-flight performance. There needs to be a real clear benefit which goes beyond appealing to CSey types and which can be used to make a compelling argument to business folk why they should let their development team(s) run off and use something new. I think several of the features I lay out would really help the language get even closer to C++ performance for a variety of computational tasks...still not as good as tuned C++, but maybe close enough that for an even broader category of problems, the extra productivity made possible by the higher level nature of the language would make it the way to go.

Why does the article not mention the name of the CPU?

You're probably not buying one at tigerdirect anytime soon, so it doesn't really matter.

It does run linux, which is kinda cool.

http://www.debian.org/ports/s390/

New users who hate XFCE?

I'm not sure what your point is. My point is that as far as software is concerned, defaults are a big deal. Losing out on users who click the defaults hurts Gnome.

There is no such thing as "download the USB image".

Wrong. From the MANIFEST: "hd-media/boot.img.gz -- 1 gb image (compressed) for USB memory stick"

There's also DVD images that will be impacted by whatever the default is.

New users who hate XFCE?

I'm not sure what your point is. My point is that as far as software is concerned, defaults are a big deal. Losing out on users who click the defaults hurts Gnome.

There is no such thing as "download the USB image".

Wrong. From the MANIFEST: "hd-media/boot.img.gz -- 1 gb image (compressed) for USB memory stick"

There's also DVD images that will be impacted by whatever the default is.

"While SmartScreen is enabled by default, it's possible for users to turn it off."

And this is what's wrong with this setup. Debian has popcon, which is a survey of what you use and how often you use it, and you can participate by having a cronjob send off the file.

http://popcon.debian.org/README

But it's not a privacy concern because it's opt-in.

If this equivalent of popcon on 8 was opt-in, this thread wouldn't be here.

--
BMO

For the majority of the users there's nothing wrong with this. So it submits unknown files to be analyzed to help future malware prevention. It doesn't identify the files as you since it's anonymous. If you're a business or a developer with a clue then smartscreen will be disabled before hand.

Turn it off if you don't like it. Microsoft is up front about it. Quit bitching.

"While SmartScreen is enabled by default, it's possible for users to turn it off."

And this is what's wrong with this setup. Debian has popcon, which is a survey of what you use and how often you use it, and you can participate by having a cronjob send off the file.

http://popcon.debian.org/README

But it's not a privacy concern because it's opt-in.

If this equivalent of popcon on 8 was opt-in, this thread wouldn't be here.

--
BMO

In other words, they want it to be possible to install Debian along with a fully-functional desktop environment by downloading only one CD-ROM image.

Which is a pretty dumb requirement in the age of cheap USB drives that are bootable. It's like requiring a bootable floppy in the age of CDs.

To be fair though, in the announcement, they do acknowledge that many people just don't like GNOME 3

Here's the commit message:

"switch default desktop task to xfce

This ensures that the desktop will fit on CD#1, which gnome currently does not.

There may be other reasons to prefer xfce as the default as well, but that is a complex and subjective topic. Unfortunatly, Debian does not have a well-defined procedure for making such choices, though it certianly has well-defined procedures for reviewing them. So, I've decided to be bold, and continue the tradition of making an arbitrary desktop selection for Debian in tasksel."

I would not be surprised if at least a few people said "I agree" while keeping their true reason--that GNOME 3 sucks--to themselves.

Seems like it, though it doesn't take much reading between the lines that the CD issue is as good an excuse as any to drop it.

Also, the value of a settlement should not be related to what you have paid for the product, but what damage was produced by the negligence of the organization that produced the product in question

So, if you pick up a random Linux distribution for free that has a serious security defect, then you should be able to sue for damages. Free is just one end of the scale of payment.

Paying for goods or services implies a level of expectation that does not exist when you receive something for free.

If you provide this protection only for paid software, people will stop using open source. To an extent, this already happens in some places. In many cases, management types I have met have refused to authorise the use of open source software because there is no warranty. There's nobody to sue when something goes wrong. Of course, this is based on a fallacious premise: that you can successfully sue a large software company when something goes wrong. If the premise becomes true because of a law, you can guarantee that every article comparing open source software with its proprietary rivals will mention this: "project foobar clearly has the best features of all the products we reviewed, but unfortunately affords you no protection under the Software Negligence Law, being free".

Give it to one of the Open Source mobile distribution developers! For example: Replicant, SHR, Debian:

http://replicant.us/
http://shr-project.org/
https://wiki.debian.org/Mobile

I run Debian Testing on my work PC, and never had any issues with it, so I agree that it's quite stable. I've even selectively installed some experimental packages (i.e a more recent version of iceweasel), and it all works flawlessly.

If you're sick of the SysV init system, Debian does have systemd available for use. There are a few issues with it, but they're pretty well documented at http://wiki.debian.org/systemd . I like the SysV system myself, but I'm going to dabble with systemd, just to see how well it starts services in parallel.

You can stop Debian services from auto-starting after upgrade or install. It's not pretty or intuitive, but it does the job. Create a file called /usr/sbin/policy-rc.d, and put in the line "exit 101". Make it executable. Your deb install scripts will not automatically restart services now. This will prevent use of the invoke-rc.d command, which the install scripts use to restart services.

I've never seen Debian re-enable a service that has been removed from the relevant rc.d directory. Very strange! A possible workaround would be to immediately disable the service via the rc.local script, but that's a bit of a hack. The proper solution would be to work with the process that is re-enabling dhcpd. I can't think of anything off the top of my head that would be responsible for this, though.

The Debian package maintainers are a decent bunch. I've generally had good experiences with dealing with them. Should probably look at maintaining a package myself, just to contribute back to the system.

The wheezy installation I ran two weeks ago told me that I needed two binary non-free packages and asked if I wanted to load them from another device.
I didn't try it though because I installed via a wired network.

It was probably related to Wireless hardware; the base Debian install these days ships only "free software", so by default you only get the package "firmware-linux-free" that contains firmware for 20 or so devices. Most of the firmware required to run Wireless cards are binary-only blobs that are considered "nonfree" in that you cannot see the source code for them, so that's why they're in the "non-free" section and don't come with the base install. [This is where Debian developers are purists, but I think it's for good reason.]

This can be frustrating if you're trying to do a network install over a Wireless card, which is why the option exists to load them from another device like a USB stick. Presumably you'd use another computer and download the necessary firmware and put it on a USB stick after finding it on http://packages.debian.org/ in the "Kernels" area.

Concatenates filesystems via FUSE.
http://romanrm.ru/en/mhddfs
http://packages.debian.org/search?keywords=mhddfs

I'll just leave here that the smallest usable installer ISO for Debian is a whopping 50mb.

The reason it takes a full CD, is that the (full 8 single-layer DVDs worth) whole Stable repository is huge, so they cram as much of the most popular stuff on that first disk, so you only need the one disk to "get started". Once installed, you can use the network to install more.

"it all" takes up about 8 single-layer DVDs. That's just the main repository... contrib and non-free adds a shitload more.

So, they try to put the base system and as much of the most common packages on the first disk, so it can be used standalone to get a useful system.

They do make a KDE disc and a XFCE/LXDE disc.
http://cdimage.debian.org/debian-cd/6.0.5/i386/iso-cd/

Debian has been running systemd for quite some time. You can still use sysvrc nomenclature, but it'll complain, but it's systemd from now on forward.

I don't think anyone would mind if there was a cool and easy way to run stuff from SID inside Stable...

There already is a relatively clean way to run things from Sid from within Stable called schroot. If all you want is to run things from within Sid in Stable, that should suffice. I used it early on in the experiments that lead up to Bedrock. I ended up discarding it because (1) I wanted to be able to run a command without worrying where the parent program is, and (2) I wanted this to work cleanly with just about any distro, not just Debian-based ones. I ended up concluding this required the ability to statically compile the chroot program (in this case schroot), and found with that requirement capchroot was preferable. Regarding your original question:

Then why not contributing to Debian the features of Bedrock?

Largely because I felt, to meet all of my goals (including the ones I described in the previous response), I needed to change a sufficient number of things that there isn't anything left to call Debian. It wouldn't run in Debian, it would replace it. If I limited myself to something which could run on top of Debian, it would be more or less the same thing as schroot. I do not propose that I could write schroot better than the current maintainer.

If that does not suffice, it would be helpful if you could explain where or how you feel I am failing to answer your question, as at the moment I'm at a loss as to where my explanation is lacking.

Well, you know. Fuck 'em. Valve is targeting Ubuntu which already includes non-free software in some repos.

You have been trolled.

This is just more of Hairyfeet's anti-FOSS FUD. Even Debian, with a policy of completely free, maintains a non-free repo. Their only constraint is that they "must not be so buggy that we refuse to support them"

2.2.3 The non-free archive area

The non-free archive area contains supplemental packages intended to work with the Debian distribution that do not comply with the DFSG or have other problems that make their distribution problematic. They may not comply with all of the policy requirements in this manual due to restrictions on modifications or other limitations.

Packages must be placed in non-free if they are not compliant with the DFSG or are encumbered by patents or other legal issues that make their distribution problematic.

http://www.debian.org/doc/debian-policy/ch-archive.html

It looks like debian developers object to maintaining all the libraries used mate, but the mate project maintains a debian repository.

http://lists.debian.org/debian-devel/2012/02/msg00257.html
http://wiki.mate-desktop.org/download#debian

I personally doubt that Mate will survive in the long run, but at least it will be interesting to see what happens.

from the debian wiki:

"Currently the Debian armhf port requires at least an ARMv7 CPU with Thumb-2 and VFP3D16"

the pi uses an ARMv6 CPU.

slashdot ate my last comment, so just check out the link

here got thin link to the fixit. in fact it fixes a lot more than just that.

http://www.debian.org/CD/

I applied for a posted Thunderbird job at the Mozilla Foundation about a year ago, saying that, but I never heard back.
http://en.wikipedia.org/wiki/Semantic_desktop

My own fumbling efforts in that direction (I have some new stuff I've made recently that is not yet up there):
http://sourceforge.net/projects/pointrel/

More comments by me on the idea:
http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-February/000401.html

The problem is that you effectively have to have two different /usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the /usr/include. Compiling and running software occasionally becomes nightmarish experience.

Debian is solving that problem the right way: multiarch. They even go beyond the 32/64 bit problem and will fully support cross-compilation, multiple ABIs and foreign arch emulation. See wiki.debian.org/Multiarch/TheCaseForMultiarch.

The problem is that you effectively have to have two different /usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the /usr/include. Compiling and running software occasionally becomes nightmarish experience.

Debian is solving that problem the right way: multiarch. They even go beyond the 32/64 bit problem and will fully support cross-compilation, multiple ABIs and foreign arch emulation. See wiki.debian.org/Multiarch/TheCaseForMultiarch.

Sorry, I broke the link. Should have been: http://www.debian.org/CD/torrent-cd/

Have you even looked at the firmware in question? It really does things as "implement fencing point support" low level crap, and it is damn SMALL.

Code is code, and even code that compiles down to a few kB at some point often requires a patch. It's quite common for new versions of firmware to be released that fix problems.

Yeah, it would be nice if it were open, but it doesn't matter very much if it is given a license that doesn't cause it to end up in Debian's non-free repo except for the lack of source

No source means it goes into non-free. There's no license that will change that. From the Debian Free Software Guidelines: "The program must include source code, and must allow distribution in source code as well as compiled form."

Seriously.

A number of us have flexibility in this arena because we've been working for the same employer for a while, or we're in charge of a department, or because we're consultants/independent contractors. I'd often play video games at work after the end of the work day, and that was fine with everyone because the work got done.

Unfortunately a number of employers are implementing increasingly draconian policies regarding software and hardware use, and rules about what is/isn't appropriate policy, even after work has let out for the day, or even if your fun side programming projects could make you a more skilled and more productive employee. Some of these policies and rules even govern the work that you do when you aren't at work, even if you do it on your own hardware.

One option would be to boot your system off a usb key/external drive. This would allow you to run Ubuntu 12.04 (or something) and hack around using Python, Ruby, Java, Processing, or pretty much anything else you can dream of. This is a really cheap solution (A 16GB usb key is about $10 online). The problem with this approach is that you're still using your work hardware, and it's harder for you to switch between your company's OS/software and your own. Also, if your company has a problem with you installing software, they might get all upset about you booting from external media, too.

If you can pick up an old laptop for cheap (maybe ask friends if they have an old one they aren't using?) then you can throw something like lubuntu or just stock debian on there, and then you'll have a great little dev machine that you can use to program up a storm. You don't need a big hard drive, and if you're using it plugged-in, the battery doesn't even need to work.

If you start to work on a project that you actually want to release, ask your boss if it's okay for you to hack on things at the office. Even if it's just a small side project released under a FOSS license, you're technically on the clock and so it's best to get an okay ahead of time.

Good luck!