hopefully this will mean that they'll have updated ISOs on their website more often.
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.
man, you don't have an ethernet internet connection, yet you are installing ubuntu...
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)
That you have never once been forced to install ubuntu without an ethernet connection suggests that it is YOUR picture in which there is something wrong!
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!?
A few things to remember for those with uncertain wireless support
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.
Grr. Can't delete/edit on my Hacker News client. Sorry.
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 don't know how I would feel about this, but I guess I would be okay if they had both a LTS and a rolling release distro.
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)
Some distros have 'netboot' ISOs that only boot into the basic loader, and pull all packages from the network. This would take longer to install be negate the 'out of date packages on the iso' problem.
Why do you believe this would be better? The main issue I see in the other comments is old/lacking wireless drivers - and a netinstall obviously couldn't help there. For the other stuff, why not just install from CD and run update once?
> (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
trustix linux, I'm sure there are others, used to do this. It was kind of annoying when installing servers because you were never quite sure of the exact versions of the selected packages, and I had a few regularly diverging servers that caused some minor problems.
Testing is the parade of preparation preceding a traditional release where they ship 53 CDs to desert island users every few years.
Testing 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.
There is already "archlinux" which is a rolling release distro.
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.
I have a feeling he thinks dev stands for in development (i.e. in progress) packages. It actually means the libraries for linking to a packages, i.e. using the package when you are developing something.
umm.. no. I mean the headers and link libraries(e.g. mysql and mysql-dev).
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.
In Ubuntu, libraries are actually included in either the main binary package or a lib* variant. The -dev package is usually just a pile of .h include files (text files), that aren't linked against anything. When the package maintainer builds the mysql package, it actually builds all the different sub-packages (mysql-client, mysql-server libmysqlclient, libmysqlclient-dev) at the same time and as such would have all of the updates pushed out simultaneously.
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.
It doesn't, Debian testing and unstable are rolling release, and they package -dev separately.
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.
Not only is Arch rolling release, but it has the AUR, the two in conjunction is in my opinion the best aspect of linux. No repositories really, or messing with anything but a few commands and odd scripts to download and keep updated nearly every program I use. As soon as I hear about new program it's yaourt * and I'm 10 seconds from have it installed.
Unless of course it's a custom kernel or another ridiculously large package in which case you may have to wait the 10s of minutes for it to finish compiling. :P
Well, the way ubuntu does it is they customize their packages and put them in the tag for the next release. Presumably, this means they'll just put them in the stable release repositories instead.
This isn't entirely true, Arch still has custom patches for certain packages and some undergo a decent bit of customization before getting pushed out.
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.
Just to clarify: i know Arch does some customization, but certainly not as much as Ubuntu. Arch also heavily relies on configuration files while I rarely edited a config file in Ubuntu. Presumably, it takes a longer time to adapt the GUI config tools in Ubuntu when new options are introduced.
I love when new updates are available, it makes me feel productive!
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.
I can update the included web browser on Windows or OS X without waiting six months and it hasn't affected my stability thus far. thats the kind of thing I imagine Ubntu would be fixing here - shipping a currrent firefox, new drivers, etc, rather than changing glibc versions.
There are a lot fewer factors in shipping a new firefox for OS X than there are for Linux. On OS X, for the most part, all of the important dynamic libraries are frozen at a single or at one of a small number of versions, everybody is either ia32 or amd64, there aren't distro patches applied to things, there isn't the wide array of Desktop Environment configurations that there is in other Unixes, etc, etc. This isn't to say that rolling releases aren't possible; it's just trickier for Linux distros.
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.
>update the included web browser on Windows or OS X without waiting six months
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 (!).
47 comments
[ 5.4 ms ] story [ 104 ms ] threadIt'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.
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)
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!?
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.
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.
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)
Testing 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.
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.
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.
10.10 is the end for me. Good riddance. Im back to debian
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.
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.
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 (!).