Ubuntu moving to rolling release?
theregister.co.uk
theregister.co.uk
But really, rolling release in production use is a little scary. It greatly increases the odds of something potentially going wrong in a routine update. I wouldn't mind more frequent releases, such as quarterly maybe; but this worries me a bit. I have a lot of trust in the Ubuntu team to be thorough in their testing, but we are all fallible and this is going to cost me some peace of mind.
You can already do this in Ubuntu and variants by adding a ppa (personal package archive?).
Also, at least on Kubuntu, the 6 month cycle isn't preventing releases that bork a lot of peoples systems. Latest one was broken from the off as not all files were uploaded to the archives and then the nVidia drivers clashed with the desktop clock (!).
Also, you have to update the glibc sometime.
The issue stopping Firefox releases for Ubuntu is that AFAICT Firefox don't bother packaging their app for Ubuntu and Ubuntu wait six months to do their own packaging.
Indeed, you have to update to a major version of glibc every few years, but I imaging most people's hardware will die first.
So I really wonder how Ubuntu will pull that off (rolling release of customized packages?!)
The biggest difference with Ubuntu (and Debian) is that they vet the packages for a much longer period of time and have a whole lot of politicking and red tape involved in getting the packages even pushed into the unstable / proposed repository.
But this would be a killer feature if Ubuntu can pull it off. I think there needs to be a fundamental difference in packaging philosophy to achieve this - for example the "-dev" being packaged separately will now need to go IMHO, etc.
This is an opinion - frequently development libraries, header files, etc. are dependent on kernel versions, glibc, etc. More so than binaries themselves. At the very least, a rolling release will change your kernel and glibc. Which means unless your header packages change in tandem, they might cause incompatibility problems.
It is less of a technical issue and more of a workflow one - would you want to handle the explosion of support requests similar to "I have mysql 5.1 but my PHP client does not connect to the DB.... oh crap, I forgot I have mysql 5.0 headers. heyyy, what gave you the right to upgrade my mysql ?"
If you go with the notion that disk space is cheap (and indeed packaging headers and dev libraries would be not too expensive in terms of disk space ), there is really no real reason to separate them both.
What you are suggesting would be near impossible to have happen without the user manually downloading deb packages, force installing using dpkg, and even then apt would shit itself over conflicting packages and broken dependencies. If someone manages to actually do that... well, they're going to have bigger problems than just "PHP isn't working right."
Rarely do packages need a particular kernel version, just ask anyone using xen or openvz where the kernel is often quite old (2.6.18) and not quite as easily upgradeable. The only time I've known of conflicts arising are when you need to use 3rd party binary drivers, or when an application is using bleeding edge kernel calls which is usually a bug upstream.
You may have a small point with glibc, but I imagine they'll just pin it to a major update every 3 to 6 months and give themselves time to test the heck out of it.
Lack of separate -dev packages is something I like very much about Arch because I build enough software that I'm happy to pay the storage cost for the headers in exchange for not having to track them down from the eventual compilation errors. It is entirely justified for a distro targeting a demographic that builds less, or with less available storage, to have separate -dev packages.
As someone else commented ISOs need to be updated more often, at the very least weekly. (It really sucks after downloading an ISO on a shoddy connection only to find out you have to download another 300mb in order to replace the software you just downloaded)
> (It really sucks after downloading an ISO on a shoddy
> connection only to find out you have to download
> another 300mb in order to replace the software you
> just downloadedTesting still gets frozen once they think they're nearing a release.
Testing still completely breaks unless you update all systemy packages in lockstep — apt+deb are not designed for mix-and-match, hell it can't even resolve multiple installed versions of the same package! You have to mangle the name and fuck up the depgraphs of every package that depends on it, forcing mutual-exclusion of otherwise unrelated packages.
Testing is not a rolling release.
Backports is intended to be rolling release for higher profile packages.
It's ridiculous that many people that get an ISO end up having issues with things like missing WiFi drivers fpr laptops and they're not able to download the updates to fix the problem unless they can get a hold of an ethernet connection to the internet.
Judging from personal noob experience and Ubuntu forums, wireless driver shortcomings are probably holding back a significant number of people who want to try Linux, don't know enough to successfully grok and use ndiswrapper, have a Dell or a Mac with a Broadcom wireless chip, and don't feel like driving to Fry's twice just to get the right USB wifi adapter just so they can install updates and use their built-in chip.
If this ever gets improved, good things will happen.
I think it is obvious what is wrong with this picture.
That aside, this will be a great improvement for ubuntu as constant progression will allow for more bug fixes and cool new features on a more regular basis (not 6 months apart)
There are probably still a lot of places where dialup or wifi is easier to come by than ethernet.
1) Don't forget you can easily try Ubuntu and wireless devices on most x86 laptops in the Live CD mode before you install. If driving somewhere to buy a USB device, bring the laptop along. You might also be able to run a Live CD and try a USB wireless device on another machine in the store (ask for permission first!)
2) If there's a Mac laptop handy, OS X doesn't need any extra software installed to share the laptops wireless access out the ethernet port, allowing simple DHCP connections. Just go to the Sharing prefs panel. (add a hub or switch to share with several machines)
3) Instead of using a Mac, some routers with free open-source DD-WRT firmware installed can also act as WiFi clients giving access to machines plugged into the ethernet port(s). Older WRT-54Gs often turn up cheap at thrift stores etc. and are ideal. (some versions have more RAM than others, check the DD-WRT site www.dd-wrt.com/ for more info) It's a good way to add wireless to desktops.
4) ... and of course Ubuntu runs well in a Virtual Box virtual machine, an easy way to use it under OS X or Windows hosts with whatever net access those already have. virtualbox.org It's a particularly simple/clean free solution for Mac users, not disturbing OS X at all.
I mean, when I think back on the late-afternoon reinstalls I would do in the middle of class in a lecture hall... Sure, I could have waited until later, but I ask you what kind of a geek would I be then!?
10.10 is the end for me. Good riddance. Im back to debian