Ubuntu 14.04 comes with Python 3.4, but unfortunately, it doesn't bundle the ensurepip module (and a host of others). By the looks of things, the idea was to use Ubuntu's own packages instead[1], but it didn't make it in time.
This means that pip being bundled by default—one of Python 3.4 coolest features—is missing. Trying to create a virtualenv using the bundled virtualenv module fails as well. Big mess.[2]
For more information on how Debian, Fedora, and others are dealing with ensurepip see "Distributions wrestle with pip" at https://lwn.net/Articles/591421/
Except even then Python 3.4's bundled virtualenv module is still broken. The omission of the ensurepip module isn't an inconvenience, it breaks Python 3.4 functionality.
This is a real shame. Python 3.4 and bundled pip support was high on my list of reasons of why I should upgrade to 14.04 sooner rather than later. I think I'll wait now until this is smoothed out.
In the bug thread linked in above, it's mentioned that it will be fixed in Debian and then included in an SRU (Stable Release Update) for Ubuntu 14.04.
Does that mean July 24th or might it be earlier, do you know?
Better to stick to their bi-annual schedule, even if it means shipping a usable but not-quite-polished release, then polishing it in subsequent months. The previous versions, from 12.04 to 13.10, are more than adequate for anyone who can't risk upgrading to what is effectively a beta or release candidate.
The majority of 14.04 installations will actually occur after 14.10+ comes out, from corporations currently sitting on 12.04, who will take a few months to evaluate 14.04, and then, finally, upgrade to it. It will be stable by the time they do this.
Because these corporations behave this way, it excludes them from the set of people Canonical has to worry about pleasing at release. So LTS releases, right on release, are actually allowed to be less stable than non-LTS releases. Because the majority of their useful lifetime, when anyone that matters is actually running them, will be spent stable.
That is pretty fucked up. The point of declaring a release, rather than just shipping nightlies, is to let people know when it's ready. Having a dog's breakfast of a major release (which 12.04 certainly was out of the gate) substantially decreases my trust in Canonical.
Think of it like this--if they waited to ship the release until it was stable enough for corporations to use... then corporations would still take four months to evaluate it, so they'd only start using it was it was four months more stable than necessary. It's a bit like cooking a steak: if you wait for it to look medium-done in the pan, it'll actually be well-done by the time it hits the plate, because it'll keep cooking in its own hot juices after you take it off. You need to take it off when it looks medium-rare, if you want to serve it medium.
Late adopters wait because they'd like somebody else to flush out the early bugs. If this is actually Canonical's plans, that 14.04.1 is the first release expected to be stable, then if I were a late adopter, I'd just wait for 14.04.2.
The let's-trick-people-into-adopting-something bit is basically an attitude of customer contempt. It's assuming that the release knows the customer's business better than the customer does. Whether it's right or wrong, it's a dick move, and acts to decrease trust.
I've only seen bug fixes in LTS releases, not changes in functionality that would address significant issues (at least under 10.04 and 12.04). Any significant change would be in a point release (e.g. 14.10) which is not LTS - so you can't have your cake and eat it too under this model.
> Better to stick to their bi-annual schedule, even if it means shipping a usable but not-quite-polished release, then polishing it in subsequent months.
Better for whom? Not for the people who take the LTS moniker seriously, I think.
It is a problem, on one set of packages that are a part of a rather large distro, not sure I would consider it a show stopper, just an annoyance.
Yes, Python is a mess. But, Python has been a horrific mess for years now, on multiple distros. I just ended up giving up on Python. Distro problems, 2/3 split, GIL and various other buggy nonsense slowly just reduced its value versus other languages.
This isn't about Python being a mess, it is about an Ubuntu release messing it up. You know there's a problem when you lose important features you'd get with ./configure; make; make install
For those of you who find the Unity desktop to be an overweight example of "designer" solipsism, try out the alternative light weight desktops like Lubuntu (LXDE based) or Xubuntu (XFCE based).
sudo apt-get install xubuntu-desktop
or
sudo apt-get install lubuntu-desktop
In fact I did that in the past weeks after being a bit weary of the Unity 8 situation. So I grabbed Debian testing and installed it. First I tried Gnome 3, then KDE and XFCE and boy, are they all ugly.
I started with Gnome 3.10 (after ignoring it for most of it's existence except once in the early time) and it failed to register simple mouse clicks in a Steam game (the firs thing I tried). It's also sluggish and ugly and hard to get anything productive done.
So I went to KDE 4.11 next. And it's as ugly as ever. The huge sound indicator at the bottom is just so ugly. And then they have what looks like a Start menu thingy to launch applications. Oh boy, that felt odd. Still miles better than Gnome 3, but nothing I'd like to see on a daily basis.
XFCE is just too bare-bone for me. It's OK in looks, but the task bars are just clumsy.
So I'm probably sticking to Ubuntu for the next LTS cycle too and see what comes of the Unity 8 desktop. Sad to see there are no real contenders.
Agree with you XFCE in Xubuntu. I just can't force myself to like Unity, stock Debian is ugly, and LXDE on Lubuntu looks flat out terrible on my 1080p monitors. Just a smeary blue and silver mess.
I don't think XFCE is perfect, but it ticks the important boxes for me. So much so that I just use it out of the box now rather than rolling my own from a vanilla OpenBox install (a fun exercise, btw).
xfce + kupfer = solution. Of course, you have to have a "Meta-Space <type first letters of app>" style of interaction mode, but I'm finding it quite an acceptable DE/Shell environment to replace the horrible, stinking mess of Unity.
You can easily customize everything on the task bar and the task bar itself. I could neither stand the sizes/fonts/ugliness but after several days of tweaking it no longer looks like KDE at all and I am very happy with it :)
I think you are being downvoted because of tone rather than fact.
Facts: Ubuntu desktop releases are available in a variety of 'flavours' including Lubuntu, Xubuntu and Gnome Ubuntu. The Kubuntu release has external sponsorship from Blue Systems. There is also UbuntuStudio that packages a lot of music/sound/graphics/video applications with a slightly remodelled XFCE4 UI. LTS status is limited to 3 years for the 'flavours' as opposed to 5 years for the Unity based Ubuntu, still one year overlap with the next LTS.
You can, as go8z says, install a range of desktop sessions on stock Ubuntu, but you do end up with a certain amount of duplication e.g. power manager, mousepad/Abiword and gedit/LibreOffice &c.
Plenty of choice so we can get our work done. It is all here...
As someone who loves window-manager designer solipsism as much as the stark minimalism of terminals, Gnome has improved quite a bit recently and I've come to much prefer it over Unity (and a suitable replacement for OSX). I'd normally lean towards something lightweight such as XFCE, but proper Gnome 3 support is necessary.
My understanding of Vagrant is that it is a meta virtualization format, so in theory one could create a Vagrantfile that points at the aforementioned vagrant boxes and it will use VMware to do the local provisioning (the Vagrant boxes even use the VMDK disk format, which should make it even easier). In theory :-)
I think if you use Packer you can create boxes in multiple formats. But once created, the boxes are just simply packaged VMs with some metadata. The formats are different for VirtualBox and VMware.
If you use Emacs and depend on Ctrl-space note that you may have to disable the keybinding in ibus-setup and restart the ibus daemon. This bug was claimed to be fixed but it wasn't for me. However I'm running Xmonad with some Gnome utilities.
The ibus in Ubuntu 14.04 uses Super+Space to switch between languages. Not the Ctrl+Space anymore. Nevertheless, it's easy to change it to any other key combination.
No, this is a new feature for the display manager. Previously in Ubuntu (with unity) the window would be the whole window area would get covered by an orange transparent film, and it was the orange film that would be resized. The actual window would only resize on release.
Yes, not exactly a revolutionary new feature, but newly enabled in unity by default.
> I thought this feature was present in OS GUIs since about 1997?
It was, until all the fancy compositing WMs like Compiz came around. Those usually had it as an option, but not as the default because it lagged way too much.
For some strange reason, the 14.04 release is not showing up for me with "sudo do-release-upgrade". I have tried to update my primary software source to their main server and main for the US, and both did not show the availability of the new release.
Upgrades between LTS releases are not enabled by default until the first point release, 14.04.1, scheduled for July. It is recommended that most LTS users wait until then before upgrading to 14.04. You could add a '-d' flag if you're in a hurry!
I used the '-d' flag and the release that it showed was the development release. I tried to proceed with the 14.04 development upgrade, but the upgrade failed.
"Hardware support - ARM multiplatform support has been added, enabling you to build a single ARM kernel image that can boot across multiple hardware platforms. Additionally, the ARM64 and Power architectures are now fully supported. "
Really? Can you do openstack with ARM/Power? what do you mean by "fully supported", does it mean ARM/Power/x86 all have the same set of packages? it has not been the case in the past.
Might want to wait until the first 'delta' (14.04.1) round June if you are happy with 12.04 for a few more months and your machines are used in production. Rough edges smoothed &c
If it is just a personal machine, have at it, I was using the Ubuntu Gnome 14.04 beta for some weeks with no major issues.
I'm still on 12.04 LTS and haven't been paying much attention to the updates since then. Are there any huge changes in between as far as the general day-to-day experience?
I don't know about everyone else, but for me "released" means I can download it from the official location - http://www.ubuntu.com/download/desktop and that is not the case yet.
I seem to remember that when 12 LTS was released that it was a month or so until you could pull it using do-release-upgrade. Something about wanting to make sure everything was stable before they pushed it that way? It's been awhile so I'm not sure.
amd64 images use BIOS or UEFI. Macs use a variant of EFI (an earlier version of what's now called UEFI), they apparently can't cope with multi-catalog CDs and the MAC variant images fix this.
Can anyone talk about how well a Macbook Pro copes with the UEFI version of Ubuntu?
Fedora 20 on a 2009 13" MBP is an unfun experience. Using the UEFI boot means you get broken graphics drivers. Using the regular boot means you have to hold boot to get the image boot menu every time you power on. (I think - I could easily be wrong). You have to make sure the disk is blessed otherwise there's a large boot delay. (Fedora 20 doesn't use the right Broadcom drivers which means some interesti g catch22 about needing to connect to the internet to get WIFI drivers but not being able to because lol no drivers.)
I don't want to rant about Fedora when most of this is my lack of knowledge. But the combination of Gnome3 and this kind of fiddling around was odd and reminded me of a much older install experience. (Having said all that, Fedora 20 is nice and does have some really nice features.)
> Can anyone talk about how well a Macbook Pro copes with the UEFI version of Ubuntu?
I don't know if this is still a case, but I was unable to use the proprietary nvidia drivers booting in pure UEFI mode (not BIOS compatible mode). I know that they've done a tone of UEFI work in grub/linux since then, so it's possible that this is no longer an issue.
So far, Ubuntu 14.04 is working flawlessly here on a MacBook Pro with retina display (2012).
Just speaking personally here. I've never been this impressed by a Linux release. If you have an HiDPI screen, then be prepared for a treat. It's absolutely stunning. It's fast, gorgeous, and near pixel perfect. Using the beta over the past few weeks has rekindled the joy and excitement of first discovering Linux as a kid (anyone remember those CDs in the back of magazines?)
The font rendering and window elements are now as sharp as OSX. The new version of GNOME provides integer scaling for all UI elements, not just text. That means no more huge fonts with tiny menu bars. Fonts look even better with anti-aliasing disabled using the gnome-tweak tool (IMHO). After years of tweaking ugly fonts & window managers, and being spoiled by a “retina” display, this is such a refreshing & welcome change to see in a mainstream distribution. After installing the restricted Nvidia driver, Unity is smooth and intuitive. It's clear they've put some effort into fixing the UI annoyances of prior versions.
This was my first time ever installing Linux on a Mac. I've always used a virtual machine. The first attempt using rEFInd was successful, but somewhat tedious. But then I found an easier way.
I installed rEFInd on OSX, booted into the Ubuntu Live Desktop, and then ran the installer with “ubiquity -b”. This worked. But Unity was a bit sluggish. This is because Ubuntu installs the open source version of the Nvidia driver by default (called “nouveau”). I learned the hard way that the restricted Nvidia drivers will not work with this boot method. If anyone else ends up with a frozen black screen, just do an F2 when rEFInd comes up, and add "text" to the boot command. Then you can remove the Nvidia drivers in console mode (although you'll need perfect vision for this, or a magnifying glass).
Now the easy way. The Ubuntu install tool provides several options on the first screen – one of which is to 'Install Ubuntu alongside OSX'.
I booted back into OSX, removed rEFInd, and deleted the Linux partitions - so now I just had the Mavericks partition, followed by free space. Download the Mac version of the ISO & create the installation USB courtesy of Google's assistance.
Now you can simply reboot OSX, hold down the Option key, and select the USB drive. Select the 'Install alongside Mac' option. It will automatically install to the free space. If you need Wifi during the installation, just open the terminal and run 'apt-get install bcm*'. This will load the Broadcom drivers & you'll be able to install any updates. Reboot to your desktop. Now use the Ubuntu software tool to install the Nvidia restricted drivers. Reboot once more, and savor the pixels and speed.
That's all there is to it. I'm going write this up in a blog post, along with some post-install tweaks (enabling the keys for brightness & the keyboard backlight, installing flux, vim/sublime, and remapping the keys in a Mac-friendly way). Just FYI, the various incarnations of Chrome do not yet support HiDPI on Linux. However, the Firefox Aurora version is fantastic (just set the scaling option in the about:config page).
Wow, this is really informative and thorough. Thanks for going through all of this. I've got an older MBP 2010 that was a real pain the last time I tried to install Ubuntu (13.10) when OSX got me pretty irate.
The other big gripe I had was the touchpad. It was weirdly sensitive and didn't understand many gestures. The weirdly sensitive part is probably the biggest deal, as any incidental brush was picked up. I guess OSX ignores certain patterns to cut down on the accidental movements.
Your experience (a lovely distribution; frustrating to install on Mac (and I am carefully avoiding placing blame on any one organisation here)) is odd in 2014.
All that kind of fiddling around is similar to the hoops people jumped through with earlier distributions.
I run Ubuntu on a Macbook Pro, and it works just fine with UEFI. However, I did have to do some tinkering with ReFind as part of the initial setup: http://www.rodsbooks.com/refind/
Peeps, don't fuck with Ubuntu on Mac hardware unless you have reFind installed. Always useful to have the installation files on the mac as well as the ubuntu drive.
The Mac images are BIOS-only and are for older Macs that don't support EFI. Modern Macs can use the regular PC images, so the name is a little misleading. For example, from the Late-2013 MacBook Pro Ubuntu 13.10 install guide:
"The 2013 MacBook Pro can recognize multi-boot CD image (e.g., Ubuntu's official iso). So there is no need to use the "mac" iso image for installation. In fact, I recommend you avoid the "mac" iso image because it is a BIOS-boot only image and will force the Mac to enter BIOS emulation mode to install Ubuntu, which will need to be fixed to boot in its native EFI mode."
Nobody stops you to install an alternate GUI on top of Ubuntu or install other Linux distro. HN is not the place for ad hominem attacks (even if you don't like the way Mark changes Ubuntu).
They never gave out personal information, they just covered your dash with ads and clicking them gave Canonical affiliate revenue. They routed the searches through their servers to prevent Amazon from associating searches and IPs when they go to the actual site.
And I (think?) this is the release where dash ads are default off.
There is no proof that they're not passing that information onto Amazon, and it's just a policy on their end. Policies can change and then we will have no recourse.
The dash shouldn't be sending any user information to begin with.
I get that Canonical needs to get profitable fast, so personally I think they should take the RedHat road and release 'Ubuntu Enterprise' or something to that effect.
> There is no proof that they're not passing that information onto Amazon, and it's just a policy on their end. Policies can change and then we will have no recourse.
Except for turning it off via the clearly marked option in the settings, or running a script that patches the feature out, or going into the source code and patching it out yourself, or waiting a few months until Canonical switches the default to "off."
They send to Amazon what you type. And default was always on. And in latest versions option to disable was removed, you had to remove one package because "Ubuntu is about simplicity"
"And in latest versions option to disable was removed"
Nope, wrong way round. After the - er - strong reaction to the original appearance of the Amazon feature, later versions had a kill switch under Privacy. It was always possible simply to uninstall the appropriate package.
If people could stop being so paranoid about nothing (the data is anonimised before sent for goodness' sake) then technology can advance much easier and quicker.
It is weird to see the total difference between privacy today (you have none and you have no expectation of any and anyone who has your data will do what they like with it) and what was happening in the early 2000s.
I get that companies feel the need to extract usable data to help fix problems (a sensible data dump is much more useful than a customer filling in a form with wierd information); or to sell anonymosed information.
But customers are right to be untrusting. Some companies have shown that they are not competant to keep data secure. Some companies have shown that they do not care about privacy.
What does sending your local search terms to Canonical and Amazon do to advance technology, exactly? All these desperate attempts at monetization off users' privacy are disgusting, and it's sad to see companies big and small stoop to that level.
Local search terms aren't sent to the web, the Dash is a search box for local and remote sources (it tells you in the description before you type anything in there. The point is for you to be able to search everything in one spot. So you can do `github:docker`, or `wiki:dinosaurs` or whatever.
You can either explicitly search locally by using Super-A, or turn off online search in the dash entirely via the privacy panel.
What's the deal with this "Ubuntu Browser" being set as the default?
I feel like Canonical has a serious Not Invented Here problem, where they keep trying to re-invent the wheel by writing their own desktop environment, window manager, browser, startup system, etc.
Rebranding stuff isn't Not Invented Here syndrome. Relax. They didn't re-invent anything. It's just Firefox with a few patches for integrating with their desktop environment.
Plus, they gave up on their startup system. They'll be switching to systemd in future releases.
It seems we were both wrong. Forhackernews was most likely referring to the new web app system. Websites that register themselves as web apps get their own launcher icons, run in their own window, show desktop notifications, etc., and they're powered by Ubuntu's custom QML-based browser which is referred to as Ubuntu Browser.
Firefox is still there, and still branded as Firefox. Ubuntu Browser isn't intended to replace it outright.
This means that pip being bundled by default—one of Python 3.4 coolest features—is missing. Trying to create a virtualenv using the bundled virtualenv module fails as well. Big mess.[2]
[1] https://launchpad.net/ubuntu/+source/python3.4/3.4.0-2ubuntu...
[2] https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/129...