Kevin Tolly makes a good point on the mysterious Novell/Microsoft deal: "Operation is really just coexistence and that is about as complicated as you and I taking an elevator together." There's no such thing as a software cooperation agreement. There are only negotiated exceptions to software non-cooperation agreements. Software, even proprietary software, is cooperative by default.
Amazon countersues IBM. All of the patents getting dragged into this fight look like patents that wouldn't pass a reasonable standard of obviousness. So watch the Supreme Court, which seems to have a "level of hostility" for the current patent-lawyer-friendly standard. Big picture, the IBM v. Amazon situation shows that IBM fears EC2 and S3. Put your startup on an Amazon backend, and you cut out a lot of what had been potential business for IBM. (Watch this space Monday morning for what should be a fun piece on web APIs, including Amazon's.)
The LinuxWorld podcast now has its own theme music, by Brian Wood. These things are sounding a lot better now. Quick notes on the setup:
JK Audio Inline Patch: connected inline to phone line. Connections: "From Phone" mic cable to Mic 1 on the mixer. "Aux Send" on mixer to "Send to Phone Line" 1/8 in. jack. Settings: "From Phone" all the way down, other knobs about halfway. Keep "Send" as low as possible to keep noise down.
MXL 990: on desktop stand with Sterling Audio PF1
pop filter and MXL shock mount. Connected to Mic 2 on mixer.
Computer: headphone out to Line in 5-6 on mixer. Audio in to Tape Output on mixer.
Mixer: Mackie MS 1202-VLZ. Has speakers plugged in to the control room outputs, but I leave those off for podcasting and phone. Aux all the way down for channel 1, part way up for channels 5-6.
Suggestions welcome.
The fun part is that thanks to a little utility called dtmfdial I can put the Inline Patch into off-hook mode and dial from the podcast rig without picking up the phone. Currently this is just pasting a phone number into a shell command but I'll have to think of something a little easier.
When I administer servers, I'm a very, very happy person because I let the Debian Project do the tweakier, less interesting parts of the system administration for me. I don't have to trust applications' own "installers" to put things in sensible places or clean up after themselves. Life is good. ("apt-get install dtmfdial", for example, or the three commands it took me to get all the software I needed for an SMTP and IMAP server installed on another box). I say again, life is good. I have one Debian box that has been up and running since 2000, and hasn't been polluted with the kind of residue that installers leave behind. Even my Debian laptop has gone since late 2002 or early 2003 without a reinstall.
But now, Ian Murdock says that software installation on Linux "sucks". That's true for stuff that isn't packaged, but for stuff that is, the Debian crew does do a good job of getting things packaged and easy to install. It's almost like being one humble user of a multi-user system where the admins are the kind of guru types who turn you on to new software. I don't really want software on my system that's not packaged, anyway -- it's one more thing to keep track of for security updates.
Ian writes, "no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there's something fundamentally wrong with this picture."
Ian has a real point when it comes to software for your bleeding-edge development box. I do want to try Jokosher, and one of its key dependencies is a modified version of gstreamer that's only available through CVS. But when it comes to your production machine, there's a lot more potential suckage in dealing with ill-behaved installers than in staying on the apt-get plan.
Podcast interview with Jane Silber and Carl Richell
Tune in to our podcast for the answers to your Ubuntu questions. What's new in Ubuntu's "Feisty Fawn" release, what does Canonical offer to system integrators, and how many virtualization systems can one distribution offer?LinuxWorld Conference and Expo San Francisco, August 4-7, 2008.
Linux Plumbers Conference Portland, OR, Sept. 16-19, 2008.
FreedomHEC Santa Monica, November 8-9, 2008.
|
|
Sponsored links |
Sucks how?
I totally fail to get his argument about decentralization. Decentralization is inherently better than centralization, in all cases, just... because? Huh? We can't even be talking about "centralization" in terms of infrastructure here, because it's very easy to distribute and install packages that are for a particular distribution even when they are not part of that distribution. OTOH, you need _some_ kind of centralization of policy because we are talking about _integration_. Having every app do integration differently would... not be integration.
Anyway, it's not like distributing binaries on linux is actually that hard. Even if for some reason you can't build native packages for the popular distributions (lots of FOSS projects manage this within a day of their releases, using only volunteers), simple no-installation-needed packages are trivial. Firefox is about as complex an app as you'll find, but if you get it from mozilla.com, here is what you have to do: 1) click the friendly green download link, 2) unpack the tarball you have downloaded, 3) inside the directory that unpacking the tarball creates, there is a program called "firefox". Run it.
Firefox uses a little shell script to set up its LD_LIBRARY_PATH and such, but most applications won't even need that -- you can pretty much get a universal linux binary by just building against an old version of glibc and statically linking everything else. Maybe the real problem is that Sun just hasn't realized that shar archives and graphical installers are last decade's state-of-the-art :-).
(Desktop icons are a real problem, but like he says, Portland is fixing that.)
Static linking?
Do you really want eight statically linked copies of gstreamer, one for each of the eight different audio applications you use to create your podcast, though? In the long run you want to get both the memory benefits of truly shared libraries and the absence of "DLL Hell", which means either (hard way) ABI standards or (easy way) intermediaries such as Debian that build everything.
Nash equilibria
(Whoops, only just noticed that you replied.)
Sure, distro integration is much better than the best possible works-everywhere "installer", and like I mentioned, even if you are distributing proprietary or bleeding-edge software, it's still entirely practical to distribute it in the form of multiple distro-specific packages.
Ian's assumption is that, for some reason, J. Random wants to distribute a single binary package, from his own website, that Just Works everywhere "windows-style". Your point is that if this is true, then J. Random is probably doing something wrong. My point is that if J. Random persists in this misguided quest _anyway_, then LSB/ABI stability/etc. are _still_ irrelevant, because there is another solution that is simpler and more robust than using the LSB can ever be, and works now. Some sort of ABI stability might give you better memory use (which J. Random doesn't care about), but it will always be more fragile (which impacts J. Random's goal of "Just Works"). So why would anyone use the LSB?
Installation of Non-Packaged Software
If you install software onto a Debian box that is not packaged yet, it's still best to use a package -- if an unofficial one. As it turns out, your example was a bad one because Jokosher is already in Debian unstable. You can add the unstable sources and install them or you can install the build-dependencies on your stable/testing machine and then build your own package from the unstable sources.
This is actually very easy in this sort of sitaution. You can find some information specifically on doing it with Jokosher.
Alternately, you can look at apt-get.org for alternative sources of packages or debs. These unofficial packages will not be held to Debian's quality standards but, like all debs, they stand a very good chance of being upgradeable and uninstallable without leaving your system in a strange or nasty state.
virtual editorial board
Good news on Jokosher packages getting into unstable -- I guess this means that the gstreamer fixes that Jokosher depends on are now in the Debian build of gstreamer.
I think I'm much happier overall with software that has gone through the build and integration sanity check that Debian provides than I would be with a bunch of installers like non-Linux platforms use. I'd like to compare a production server that installers have been scribbling on for five years to my Debian box that has had stuff installed, uninstalled, and upgraded for that long.