Sun Puts its Weight Behind Ubuntu Linux

fak3r writes "Sun today announced that they are putting their weight behind Ubuntu Linux. While Ubuntu has been many people's desktop Linux choice for a few years now, with its Debian heritage, you can see what kind of server it could be. Slap that on the new Sun 1Us with the new Niagra T1's CPU, the one that'll have four, six or eight cores each, and go to town."

there's a typo ;)

[Janek Kozicki]

it's Niagara T1 CPU [sun.com], not Niagra.

How far we've come...

[nganju]

Remember this quote from Scott Mcnealy [linuxtoday.com] a few years back?

Re:would Sun put all their weight behind apt-get?

[Ant P.]

Don't forget Sun thinks they're competing against Red Hat. RPM would be the last package system they'd want their name behind.

Hope you're not in a hurry

[Analogy Man]

If you are going to town with the Niagara chip I hope your application is appropriate for it. If you need to chew up threads...great. If you have a single threaded application you will have 2X the response time of a Sunfire v440 which is hardly a FAST machine (think medium duty truck). If you are doing any floating point processing the FPU is shared across the 32 processors (8 cores / 4 threads) the application sees.

Re:Server?

[arachnoprobe]

Nope, you are wrong. Ubuntu/Canonical offers 5 years of support for "Dapper Drake" as a server. Only because you don't consider it at Desktop OS (like lots of other people, including me) it is not unusable on a server.

Re:would Sun put all their weight behind apt-get?

[Neil Watson]

I do not believe that the Solaris packaging tools handle dependancies well. It is a mostly manual process.

Re:would Sun put all their weight behind apt-get?

[chicagotypewriter]

Sun has denied [itweek.co.uk] that their move to back Ubuntu is a move against Red Hat, or SuSE. Whether or not that is believable is another question, but thats just what they have said.

Re:With friends like these...

[KingArthur10]

Luckily, in Ubuntu, J2RE et al are available via the multiverse. Thank you sun for making a compatible liscense.

Re:would Sun put all their weight behind apt-get?

[Godji]

Oh, please. Every u83r g33k / l33t haxx0r knows that Gentoo's portage easily pwnz both of them!

apt-get is not a Linux distribution

[WebCowboy]

Sun is endorsing Ubuntu, a Linux-based operating system. There isn't anything indicating that they are favouring any particular software packaging system. Dpkg/apt-get might be the way Ubuntu keeps its own house in order but nothing prevents anyone from installing and maintaining RPM packages on a machine running Ubuntu.

Merits of dpkg aside, SUN may give standards compliance a high priority in its products, and like it or not in order to comply with ISO23360 the operating system MUST support the installation and management of RPMs (it need not be the native package system of the OS, but ALL ISO23360 compliant applicaitons are distributed as RPM packages). SUN could very likely contribute its resources towards making Ubuntu comply with ISO23360. Mark Shuttleworth himself stated that this was a goal for upcoming Ubuntu releases so they would be on the same page. Therefore if the ISO23360 standard gains traction it could mean that installing RPMs on Ubuntu machines could become more common than you'd think, especially for companies like my employer--large enterprises that salivate over anything with "ISO##### Compliant" on it...and guess what SUN's customer base is?

Oh yeah...perhaps I should explain what this ISO23360 is. Basically it is a standard that specifies a set of requirements for Linux-based OSes (file structures, included shared libraries, software packaging format, etc) to allow compliant application software to be easily deployed and executed on any compliant OS without the need to recompile and/or re-package for each OS as is the case today with Linux systems. It is more commonly known as LSB3.1 ;-)
 

Re:Java support for Debian at last?

[kbmccarty]

Perhaps we'll see a repository for Java .debs at last, eh?

You must have missed the big news: official packages of Sun Java .debs were uploaded into Debian's non-free archive yesterday.

The announcement [debian.org]

Link to the page for the "source" package [debian.org] (I put "source" in quotes since it actually contains tarballs of the binaries, but you can obtain real source code in the sun-java5-source [debian.org] binary Debian package.)

License [java.net] and FAQ about the license [java.net] under which these packages are made available (note in particular that it permits sublicensing for derived distributions).

As an aside...

[Ayanami Rei]

Linux on Sun boxes also calls their disks sda, sdb, hda, hdb, etc.
Conversly, Solaris 10 on opteron == /dev/rdsk/cXtYdZsQ galore.

Re:Server?

[musther]

You can set up root in the 'normal' way, this may be default in the server install (if it's not, that's something to think about for the future).

Re:would Sun put all their weight behind apt-get?

[digidave]

Non-Debian users will think you're joking, but the truth is that Debian packages are several orders of magnitude better than any other distro's. Slackware may come closest. I think the difference is that Debian packages feel like they've been made by people who love Debian and love the software they're packaging for Debian. There are no bad packages in Debian stable and packages don't do anything they're not supposed to do, like break compatibility.

Debian is the only OS I use in which I feel confident upgrading a production server without extensive testing. 100 packages might need upgrading, but I know it will work and won't break anything.

Re:Debian

[MoogMan]

What will Ubuntu provide over Debian for a server?

Commercial Support.

RPM in ubuntu :: HOWTO

[hummassa]

Alternative 1 (dirty, two steps):

$ sudo apt-get install rpm
$ sudo rpm --force-all -ivh PACKAGE.rpm

Alternative 2 (cleaner, four steps):

$ sudo apt-get install rpm alien fakeroot
$ fakeroot alien PACKAGE.rpm
$ sudo dpkg -i package.deb
$ sudo apt-get -f install # will install any dependencies

Alternative 3 (suppose multiverse is in sources.list)

$ sudo apt-get install package ## it is probably there :-)

Re:Main problem with yum - slowness

[morgan_greywolf]

Similarly other posts say that the advantage of apt is the Debian repositories. That's an advantage of Debian, not of apt. Ubuntu uses apt and dpkg, yet Ubuntu's package repository != Debian's package repository.

Actually, Debian universe and multiverse are in the /etc/apt.d/sources.list by default, they're just commented out by default. You can enable them in synaptic or Ubuntu's default package manager (based on synaptic) with a couple of mouse clicks.

Re:With friends like these...

[tyrr]

"/dev/rdsk/c0t0sUpercalifragilistic" is actually a SysV4 standard. HP or IBM would do the same.

Re:Time to revisit!

[Compenguin]

> If Java could release supported GTK bindings instead of having to rely on Swing It would be a dream come true.

You want Java-GNOME http://java-gnome.sourceforge.net/ [sourceforge.net]

Re:Debian

[swillden]

I use Ubuntu as the server for the LAN in my house. I have to say it has one very big advantage over Debian. It's stupid easy to install.

Ubuntu uses Debian's installer, so Debian is *exactly* as easy to install as Ubuntu. Specifically, Ubuntu uses the new installer that Debian released with sarge. I suspect your previous experience with installing Debian predated sarge.

Ubuntu actually makes a really terrific server, no disadvantages when compared with plain Debian.

The disadvantages of Ubuntu as compared to Debian are (1) Debian stable is more thoroughly tested and therefore more reliable and (2) Debian has a much larger package repository than Ubuntu. Of course, if you enable Ubuntu's multiverse repository, you get all of the Debian packages as well, but they haven't been tested with the Ubuntu system, exacerbating (1).

That said, Ubuntu is a perfectly reasonable choice for a server OS, IMO. I prefer Debian, but mostly because I'm already extremely comfortable with it.

Re:Main problem with yum - slowness

[Anonymous Coward]

Modifying your yum repositories (under /etc/yum.repos.d/) to use the 'baseurl' directive, instead of the 'mirrorlist' directive, should fix this. I use either download.fedora.redhat.com or mirrors.kernel.org, and have no issues whatsoever with yum.

Re:Didn't Ian Murdock try this already?

[xenocide2]

Partly, it's a matter of timing. When Progeny started, it was 2000. Perhaps the height of the .com bubble. There were a lot of competitors to Debian. Redhat was still officially supporting a free desktop OS. GNOME hadn't yet recieved a critical look via a Usability study that demonstrated that half the crap in it was not only useless, but confusing. Distributing an .iso was feasible but finding software to burn them was still arcane. Crappy modem support was still a fundamental problem. A notable constants though: Debian stable was two years old, and woudn't be out for another year.

By the time Ubuntu came out, Fedora had taken (and partly dropped) the torch, GNOME was vastly improved, KDE wasn't in danger of being placed in non-free, and a lot of Linux providers dropped out after the .com crash.

The other half of the equation was simple: goals. Shuttleworth aims to be truly successful [launchpad.net], not just something to feed himself and his kids (*cough* his progeny *cough*). He capitalized on the fact that Debian stable was so sorely out of date that when everyone else stated they'd not be packaging xfree 4.4, debian had just gotten 4.3 into unstable. Ubuntu's release schedule is (usually) designed to be synchronized with GNOME so that, for a brief moment, Ubuntu is one of two places to go for the latest (the second being CVS). Shuttleworth recognized that a number of people didn't have access to windows based CD burning software, or perhaps the knowhow to find some, and funded ShipIt.

While Murdock was aiming for NOW (network of workstations), Ubuntu's initial focus was on laptop support. Even in 2000, the question was asked "why do you think your SSI will succeed in today's environment?" If the answer was "it's open source," well that answer clearly wasn't adaquate. NOW assumes a very specific kind of resources, and adds a lot of complexity to gain something that rapidly falls in price. It might be interesting, but you have to own more than a couple workstations to make it worth your time, and it doesn't really aid mysql or apache much.

It almost seems like Canonical learned from Progeny that half of selling Debian support was going to be making people want it, instead of capitalizing on some imaginary underserved market segment looking for ways to reduce the cost of Debian deployment. As always, sales, sales, sales!

Re:would Sun put all their weight behind apt-get?

[00lmz]

The real reason [debian.org] for choosing Ubuntu/Debian would be the Debian Policy [debian.org], not any packaging format. A quote from the linked page:

People often say how they came to Debian because of apt-get, or that apt is the killer app for Debian. But apt-get is not what makes the experience so great: apt-get is a feature readily reproduced (and, in my opinion, never equalled), by other distributions -- call it urpmi, apt4rpm, yum, or what have you. The differentiating factor is Debian policy, and the stringent package format QA process (look at things like apt-listchanges, apt-list-bugs, dpkg-builddeps, pbuilder, pbuilder-uml -- none of which could be implemented so readily lacking a policy (imagine listchangelog without a robust changelog format)). It is really really easy to install software on a Debian box.

This resembles cargo cult religions: that is, apt-get is the visible aspect of Debian's policy system, the same way that cargo-cult practices saw runways and other characteristics as the source of western goods ("cargo"), and built their own replicas, complete with fake wooden headphones for control towers. In the same way, other distributions have created the shallow visible aspect of Debian's packaging infrastructure, without addressing the deep issues of policy. Worse: the conflicts of technical requirements and marketing / economic imperatives often work at cross purposes. Less perversely for most GNU/Linux distros than for proprietary software, but still clearly present.