"Google is a paying customer for Canonical's Ubuntu Advantage support program."
Good news for desktop Ubuntu users.
'Chris Kenyon, who is Canonical's VP of Sales and Business Development, and was present for Bushnell's talk confirmed this and added that “Google is not our largest business desktop customer.”'
""We chose Debian because packages and apt [Debian's basic software package programs] are light-years of RPM (Red Had and SUSE's default package management system.]”"
Would someone mind giving a brief overview of why apt is better than rpm (or why someone might think this?)?
I'm a Debian fanboy, but in all honesty, the RPM-based distros have long since caught up with apt in terms of sophistication.
I did find yum (the apt equivalent used by Red Hat and friends) a bit slow (it's written in Python) and slightly rough on the usability front in some cases, but perfectly serviceable.
Mandriva and its derivatives (Mageia is worth looking at) use urpmi to provide the equivalent of apt. I really, really like urpmi, but none of the distros that use it have satisfied me (for unrelated reasons).
SuSE and friends have advanced package management baked into YaST, which handles other configuration and setup tasks as well. I haven't used SuSE in ages, but it the package management seems pretty robust.
Yeah, i've always found that quite odd. Do you seriously need to refresh the package db every. single. time? I might agree that cron-based/user-initiated solutions are suboptimal (some users will just not bother, which is a security and support problem), but surely there is a compromise, like limiting the refresh to once a week.
(Cue some RedHat fanboi saying "but it's easy, you just do xyz" -- no, it's not easy unless it's default behaviour. Otherwise we might as well just run OpenBSD, because opening network ports every time you have to sneeze is "so easy".)
Here's an example of why dpkg (and its associated tools) is more sophisticated than rpm (and its associated tools):
While building a debian packakge, there are tools which will scan all of the binaries, determine which symbols they are using in a shared library, and compare that with a list which shows when a particular symbol was first introduced to that shared library, and use that to calculate the minimum prerequisite version for that particular shared library. This is important, because otherwise you could install a new version of a binary, and it might not work because you don't have a new enough version of its dependencies.
I recently had a user who complained about this with e2fsprogs, when it used a new interface, who demanded that I bump the major version of the library (thus declaring it backwards incompatible) because this was the only way rpm and yum would automatically figure out the version dependency. I refused, and instead asked them to manually update the version dependency in their package, and pointed out that debian could automatically figure out major and minor version dependencies without needing any manual work.
For an example of this text file which maps symbol versions to minimum package versions, please see:
P.S. Because RPM doesn't do this sort of thing automatically, sometimes the only safe thing you can do to make sure there aren't any overlooked version dependencies is to download the latest versions of all of the packages installed on your system, and run the command rpm -Fvh *....
I'm just a casual user, and I didn't really notice any difference between deb and rpm. But I did notice a significant difference between apt and yum. Yum was much slower and less clever in figuring out dependencies. I've had yum uninstall unrelated programs sharing libs with the one being uninstalled. It seems like apt(itude) has more advanced resolution algos built in. Plus more is avail as deb than rpm, no need for manual download via websites.
It was never about the packing format (dpkg, rpm) nor about the management system (apt, yum)... it was ALWAYS about the number of packages and how well integrated they were and still are. Debian based distros still have the upper hand here as everything belongs to the official distro and is packaged as part of the whole system. RPM based distros all seem to go for the idea of the smaller core set of packages with other repositories filling out other parts of the ecosystem. It just doesn't work as well.
I haven't noticed much of a difference between apt and rpm, but the one thing that keeps me on Debian and Ubuntu (versus other distributions or OS X) is the huge and properly maintained Debian software repository that has no competition.
I haven't used rpm for a while having left redhat for ubuntu years back so this may be out of date: but certainly at the the time rpm was famous for "dependency hell" and deservedly so - almost everything I tried to install was a circular nightmare of incompatible dependencies. To the extent that i'd have to give up or resort to compiling from source. OTOH, apt was an absolute dream. It just worked. It'd fish anything required out of remote depository. There were never any version incompatabilities. I've never once had a failed install. On moving to apt I never looked back and would never use rpm again: indeed for me apt was Ubuntu's "killer feature".
> I haven't used rpm for a while having left redhat for ubuntu years back so this may be out of date: but certainly at the the time rpm was famous for "dependency hell" and deservedly so ...
True, but since then yum has taken over from rpm, and yum automatically resolves dependency issues. Just saying.
All major distributions have tools that avoid dependency hell, in one way or another. The bad old days of rpm trying to sort things out on its own -- and failing -- are gone, and good riddance.
> On moving to apt I never looked back and would never use rpm again.
Yes, but it's important to point out that Red Hat / Fedora users don't use rpm any more either.
apt is not the equivalent of rpm. dpkg is the equivalent of rpm. And dpkg is equally dumb (both of them "by design" - it's not what they're meant to do)
But Yum and Apt as well as other tools have been available to do automatic dependency resolution on RPM based distros for many years - I believe at least apt-rpm predates Ubuntu.
They aren't comparable and just show that the speaker hasn't used the alternative in over a decade. RPM is a packaging format like dpkg. Apt does dependency resolution like YUM/urpmi/zypper.
I do a lot of packaging for both Fedora and Debian and here are my thoughts:
* Building Debian packages is a horrible experience. Writing an RPM spec file is much nicer and easier.
* Apt is much much faster than yum.
* Using a true (NP-complete!) SAT-solver (ie. zypper) is lightyears ahead of anything Debian or Fedora are currently doing, although there's a project underway in Fedora to fork yum to use a SAT-solver.
What are the practical benefits of using a SAT-solver? Is it faster? I haven't had any problems with the results of apt's algorithms, but maybe others have. When installing/upgrading stuff, the update step seems to be much slower than the other steps.
Package upgrades are an example of SAT (the satisfiability problem)[1]. Apt and yum don't recognize this result and instead use a bunch of ad hoc rules. These often fail, when they could succeed. SAT will always find the answer, eventually, if there is one.
Now the issue is that SAT is NP-complete, so it could run for a very long time before it finds a solution. But there are very good solvers which "most of the time" (meaning, basically always) find a solution in a short time. They are also open source projects[2].
There's been an existence proof (zypper) that using a standard SAT solver is possible, works, and is fast.
I understand what using a SAT-solver implies, but I haven't noticed apt failing often in practical terms. The heuristics used seem to work fine for me.
I'm actually surprised that this is the case. I dont know if yum's slowness (as a by product of its implementation) is one of its shortcomings, but I always presumed that it was more sophisticated as a package manager. Especially, since it implements a SAT solver (libzypp) that is pretty nifty.
I have heard that it managed package dependencies (cyclic, broken packages, etc.) much better than aptitude.
I'm an Ubuntu user, so the above is pure speculation - but could someone answer whether the SAT solver causes the slowdown ?
The SAT solver work is great, for anyone interested check out http://www.mancoosi.org/, there's even an annual competition for solving Linux package upgrade problems.
Note that both apt-get and aptitude, together with dpkg, are part of APT (advanced packaging tool), which is the suite of tools handling .deb packages.
While I'm at it, neither apt-get nor aptitude are simply front ends to dpkg - both have fairly complex (and different) policies for how to handle dependency conflicts, etc, while dpkg makes you do everything by yourself.
Better integrity checks, mostly. Built in checksums of files, stricter limits on what you can do as a package ( no controlling terminal and so on ) whereas in deb it's "optional" and "flexible" (aka. not built in and maybe people will get together and decide something)
rpm has some build time analysing tools to track library (.so, python, perl, php, ruby imports) use and annotate this as dependencies.
This above feature is one that causes the mess when you don't have the full dependency graph for a package, because rpm by itself does no dependency resolution.
Whenever I've wanted to package .deb's I've just blatantly ignored the official way, and opted for a much simplified setup (write the control file and the pre/post-int scripts, and use a Makefile to build the filesystem hierarchy required and run the appropriate tools).
I agree, though, as much as the RPM spec files are horrible, it's still overall simpler.
As always, another link bait zdnet article with a flashy title and zero content. Normally I don't bite but I guess I have been taken in and got exactly what I expected. How come zdnet articles still get posted? I have yet to see one that actually brings content to the table that is new or informative.
"That said, desktop problems , even on Linux, will happen"
Sounds like something written by someone who's spent almost no time using any of the Linux desktop environments (let alone trying to connect to a projector). And sure, Mac lovers might move to Unity rather than Gnome, Xfce or whatever, but presumably only if someone forced them to use Linux in the first place.
Also hilarious is the suggestion that Google's graphic designers are running Ubuntu, considering Creative Suite is Windows and Mac only. I've received seen plenty of creative out of Google, and none of it was done with the GIMP.
I've been using Ubuntu for years on my laptop, both for work and for home entertainment.
I've had no problem connecting to a projector, whenever I needed to do that. Of course, I was careful when buying my hardware. Also, problems do happen, that's why I'm staying on LTS and personally I consider the intermediate versions as being beta-quality. And the Unity stuff is not stable and is too rigid, so I switched to Xubuntu (Xfce), which is more stable and stays out of my way.
Ubuntu may not be ready for normal users that would want it at home, but a company like Google has people ensuring that these workstations are compatible and that upgrades work properly. They also afford to pay for support from Canonical. So the employees choosing Ubuntu can benefit from its advantages with less downsides.
considering Creative Suite is Windows and Mac only
If I were a designer I would definitely pick OS X over Ubuntu, but on the other hand you can run Creative Suite in a virtual machine like VMWare. And you can even install an X Windows server on your Windows VM and make that Photoshop window work on your desktop as if it was a native app, only styled differently.
Also, designing stuff in Photoshop is not the only thing a good designer does. A good designer also writes HTML, CSS and preferably also do a little programming for proofs of concept, amongst others. Those changes may involve running a complex app on your localhost. And it's definitely easier to have access to the same tools that the developers use. And it's preferable to use the same operating system Google uses in production for its servers (at least a virtual machine).
none of it was done with the GIMP
True, designers don't use GIMP, but GIMP is a perfectly capable app for doing design work. Along with Inkscape. The only thing truly keeping designers on Adobe's Creative Suite is that Photoshop is a de-facto standard, so it's easier to get training and support for it and it's also easier to send the raw files (PSDs) to other people.
I've had tons of mac users go goggly eyed over how well gnome3 handles multi monitor (automatically creating profiles for different monitor sets that are plugged in, and remembering exactly what it's supposed to do under various circumstances with zero setup).
Caveat: It definitely does the magic best with an intel graphics chipset, because proprietary blah blah blah
Point is, if you are referencing projector problems, you're talking about a far away time now...
I don't doubt that Google is a very public and very popular target for those looking to breach insecure systems. Having said that, I've heard this "we are the ones that need this the most" sort of argument that they use to justify their in house network authentication by many other companies in many different scenarios. However, most of the time, the problem they are having applies to just about everyone else in the field they are a part of. Which is why open source development has been so successful. Many with the same problem, helping to implement a common solution, instead of a custom one for each of them. So I wonder, what are the deficiencies of other existing 'network authentication' solutions out there? Why couldn't they help improve those? Why not contribute whatever improvements they've mode to this area?
Have you heard about Google Authenticator? http://code.google.com/p/google-authenticator/ It's a wonderful, standards-based, open-source project that brings two-factor authentication to Android, iOS, Blackberry, and PAM.
I doubt Google would want to talk about every single way that we try to secure our networks from hackers, but Google is pretty good about open-sourcing things (or publishing papers) to contribute to the industry's security practices.
I agree, Google does open up a lot of projects and publishes a lot of papers as well on their work. I guess my comment was a bit of a gut reaction to the wording used that entailed "our problem are unique" which are many times used to justify brand new proprietary projects.
I imagine whats used is based on a combination of open source projects (either theirs or others) with their own secret sauce. Which is pretty standard process I guess.
Alright, maybe I commented too early. The wording threw me off.
I don't think they do. As far as I understand it, employees can choose Mac, Goobuntu or Windows (though windows has to be justified b/c of the higher overheard of support). Sounds reasonable to me.
From talking with Thomas before, if I have this correctly, is that Google doesn't allow offsite development. So it seems most Googlers have a desktop for development and an laptop for other things with NO code on it. I may have that wrong, but I'm sure some Googlers here can verify that or not.
It's not "offsite development" that's prohibited so much as not allowing source code to be stored locally on laptop HDD's (even with full-disk encryption). You can develop remotely over SSH, NX, NFS, SSHfs, etc., you just can't have the source (or compilation artifacts) on an easily-stolen device.
Java developers that use Eclipse or IntelliJ seem to work remotely pretty well using NX or VNC to get a remote Linux desktop, and Googlers who work on open-source projects obviously have different rules for that code.
I'm actually not sure what the IOS devs do. They might have different rules since their projects are more standalone and not tied into the rest of the main Google source tree, but it might also be that they just develop on-site. You could probably be fairly successful with XCode using something like SSHfs if you're on a fast enough connection, but I don't know if anyone actually does that.
That's what I was thinking. I've seen this headline on a few sites in the last few days and the commenters all seem to be talking about Linux in the past tense. Apparently I didn't get the memo because my laptop with Ubuntu on it is still working fine and the projects that I make use of haven't missed a beat. That's some kind of "dead".
Ubuntu works for me and my wife and has for years. I pine for the days of Gnome 2 but that's not coming back. If Unity could be made into Gnome 2 but keep Unity people happy then that would be cool.
Linux Mint also has a desktop, Cinnamon, that resembles Gnome 2: http://cinnamon.linuxmint.com/. I haven't tried Cinnamon, but I've used Linux Mint before and will most likely be switching to Mint next time I reinstall Linux.
This is Gnome3 configured to look very much like Gnome2. The primary differences are that "System Settings" (and some other things like printer configuration) moved to the "gear" at the far right of the top bar and you need to use <ALT>-right-mouse to add shortcuts to the top bar.
The <ALT>-right-mouse may only work with Gnome Classic (selected when you log in).
When it's difficult to use Windows at one of the world's biggest Tech giants, you have to wonder how long windows can stay relevant in the tech/dev space.
Actually, having worked at Google and used Goobuntu (which was great) and then tried to use Ubuntu LTS outside the constant vigilance of a large support team, it isn't a threat to Windows (or OSX).
The challenge in an Enterprise that doesn't have a stock to penguinistas to keep it on the straight and true, it goes pear shaped at odd times for unpredictable amounts of time. That and the fact that there is no "real" third party software for it makes a lot of folks sad. (see the other conversation on HN on why that is)
It's always been a big challenge to manage thousands of MS Windows desktops and it certainly has not gotten substantially better with BYOC / mobility of users.
The real challenge for MS will come with establishing Windows 8 in the corporate space - don't believe that it will be happening without substantial changes / limitations removed by MS.
Reminds me a bit to the first versions of Windows activation / update a few years ago when MS had to paddle back almost the whole way before commercial customers started to upgrade to the new Windows version.
The Arch Build System is utterly wonderful. All you do is define a PKGBUILD and it will handle downloading sources, compiling them, and creating a package. It's so simple that once you've done it a couple times it's basically fuck-all effort to create them for whatever you want.
Then all I need to do is run pacaur -y dmenu-dogs (pacaur is an AUR helper, which automates the process of downloading the PKGBUILD + any patches/local sources, running makepkg, and installing it) on my other boxes and it sorts everything out for me.
Pacman itself is also very lightweight and fast, and has a very simple and clearly separated API. Want to know what package owns a file? pacman -Qo /usr/lib/blah. Want to check a package has all it's files? pacman -Qk mypackage. Anything removing is -R, anything querying is -Q, anything installing (syncing) is -S.
The last thing I love about Arch is the wiki. It is fucking AMAZING. There are well explained and thought out posts detailing how to install and configure a vast, vast range of software. I even refer to it when I'm not using Arch.
And installing yaourt[1] makes using PKGBUILDs from AUR and ABS, and binary packages from the repos amazingly transparent and fast. I've never heard of such a level of flexibility on package management.
For instance, you can install the precompiled chromium from the repos with yaourt -S chromium; if you need to recompile it from ABS, throw a yaourt -Sb chromium and you are done. To install the binary build from AUR, yaourt -S chromium-browser-bin will do it.
Thanks for writing that. Arch Wiki is amazing. Ubuntu has also started writing and updating their wiki. AUR still makes your life easier for examples android-sdk, android-sdk-platform-tools, android-udev, and android-eclipse will install complete android development environment including ADT Plugin, etc.
Not related to the content of the post (which, it seems, is mostly a rehash of already-available data), but I must say, the comments over at zdnet must really be going downhill-- there are some truly horrific examples at the end of the article.
A typical engineering setup. There are quite a few of us using Goobuntu Thinkpads or Chromebooks. (Since you can't have code checked out on your laptop, a Chromebook is not as disadvantageous as one would imagine.)
Good news for desktop Ubuntu users.
'Chris Kenyon, who is Canonical's VP of Sales and Business Development, and was present for Bushnell's talk confirmed this and added that “Google is not our largest business desktop customer.”'
Better yet.