Ubuntu's multisearch surprise
The bug report filed on July 21 had to do with broken functionality. It seems that, when using the version of Firefox distributed with the third Karmic alpha release, typing a search string into the "awesome bar" no longer takes the user directly to the first search result from Google. Instead, users end up at a Google "search partner" page listing the results and, of course, advertisements. Other quick searches, including stock quotes and currency conversions, also break. A related change is that opening a new tab now brings up an Ubuntu search page instead of a blank page - a change that some users find jarring.
It turns out that Ubuntu has placed a new Firefox extension, called "multisearch," into the Karmic alpha release. In essence, multisearch rewires the various search mechanisms built into the browser, causing them all to pass through Ubuntu's partner page. It can be disabled by going into the "Tools->Add-ons" menu, but, by default, it is installed and active on all systems.
So why was this done? Rick Spencer, Ubuntu's desktop engineering manager, explained the reasoning in a fair amount of detail. The "new tab" change is an attempt to improve the user experience - something that Mozilla developers are working on as well. The search change lets Ubuntu know which search mechanisms are being used most; beyond that, he said:
Generating revenue that supports the project is a feature, not a bug. However, we are mindful of not throwing the baby out with the bath water. In other words, we must strike the balance of continuing to deliver a top notch user experience while taking advantage of revenue opportunities.
Ubuntu users are not necessarily opposed to the idea of revenue going
toward the development of their distribution; it's a "feature" they can
support. Many of them are, however,
rather less thrilled about their search data being used to that end.
Rick's explanation - "it's simply the same data that is already sent
to Google and Mozilla: the requested search, and the channel for the
search
" - does not appear to have made anybody feel any better. As
might be imagined, some of the more vocal users are throwing around words
like "spyware" and "privacy violations." But even calmer voices are
concerned that this "feature" was silently added to their systems, that it is
not something they wish to have around, and that there has been little talk
of privacy protections for the accumulated data.
Apologies from the Ubuntu side have been few and far between. Ubuntu Mozilla maintainer Alexander Sack justifies the change this way:
Of course, one should bear in mind that default Ubuntu installations are "opted in" to the ubuntu-desktop metapackage; very few users will have deliberately made that choice.
The other thing to bear in mind is that this feature appears in an alpha
release - and that users did indeed make a deliberate choice to install
that release. It's not uncommon to find unpleasant surprises in alpha-quality
distributions, even if it's a bit more uncommon for those surprises to have
been introduced deliberately. Alexander says that multisearch "is not
intended to stay forever - at least not in its current form.
" One
can interpret that to mean that some of the more annoying failures will be
fixed. It's possible that the entire thing will be taken out before the
end of the alpha-test period. But nobody from Canonical is saying that now.
A great deal of trust is placed in Linux distributors; they have the ability to inflict all kinds of unpleasant behavior on their users. Distributors seen to abuse that trust are not likely to retain their users for all that long, though. The beauty of free software shows through in a few ways here: undesirable behavior is very hard to hide, it is quite easy to remove, and, if all else fails, one can switch to a different distribution with minimal pain. Ubuntu is probably not losing any users over this episode - yet. But any user of this distribution who is concerned about this behavior may want to watch closely to see what decisions are made between now and the final Karmic Koala release.
(Update: multisearch was removed from Ubuntu on
August 11.)
Posted Aug 7, 2009 23:33 UTC (Fri)
by beuno (guest, #44010)
[Link] (16 responses)
I love that the community holds Canonical to such high standards, but this is really blown out of proportion considering Ubuntu's track record of delivering great user experiences.
Posted Aug 8, 2009 9:38 UTC (Sat)
by coriordan (guest, #7544)
[Link] (15 responses)
If someone wants to test usability by collecting personal info about me, I might let them, but I want to be informed before the fact.
The silent data collection was intentional. The usability problems were an accident, and we're lucky they occurred! If not, this data collection behaviour could have silently ended up in a non-alpha release.
Posted Aug 9, 2009 4:02 UTC (Sun)
by jspaleta (subscriber, #50639)
[Link] (14 responses)
I think the horse is out of the barn a little on the privacy issue. There's been little to no controversy about how Google and Mozilla share data and revenue for existing firefox installs in our linux distributions of choice. I doubt Canonical would have access to any more information that Mozilla is already able to get through Google. All this really does is potentially give data and revenue to Canonical that would have otherwise gone to Mozilla. Should you trust Canonical any less than Mozilla?
Though I do think that Mozilla could take this opportunity to talk more about how the existing partnership works and what sort of information they collect from existing firefox users and make some suggestions about what is appropriate from a privacy policy notification standpoint.
-jef
Posted Aug 9, 2009 21:43 UTC (Sun)
by coriordan (guest, #7544)
[Link] (5 responses)
> I think the horse is out of the barn a little on the privacy issue.
I've never understood this attitude. These are our rights,
and we'll fight for them even when we're over-powered and when it
looks like we're losing.
Our privacy is being eroded by Google with the help of Mozilla.
Google should stop that, but I have low expectations from Google,
they're not part of our community. Mozilla should stop that. Until
they do, we should not trust them as a source of free software. We
should use builds of Firefox that come from people we trust - be it
Debian, gNewSense, GNU, etc.
It's sad to see that Ubuntu cannot be added to the list of software
providers we can trust.
Posted Aug 10, 2009 16:30 UTC (Mon)
by sbergman27 (guest, #10767)
[Link] (4 responses)
>I've never understood this attitude. These are our rights, and we'll fight for them even when we're over-powered and when it looks like we're losing.
Note that Jef does not offer an opinion as to whether the Google-Mozilla situation is good or bad. He *observes* that it has stirred up little controversy.
FWIW, I use Epiphany. And will be moving completely to Epiphany-Webkit as soon as practicable. For a host of reasons which include, but are not limited to, the effect that money, and Mozilla Corp, have had upon the Mozilla Foundation. Mozilla Corp is supposed to be a subsidiary. But it's pretty clear that the tail has been wagging the dog for some time now. In fact, almost from the very day that Mozilla Corp was established.
Posted Aug 10, 2009 18:23 UTC (Mon)
by jordanb (guest, #45668)
[Link] (3 responses)
One thing about it though, is that I feel that it's a net privacy loss, because I lack the customize-google and adblock plugins.
So when I use firefox, I can easily screw around with the google cookie, block analytics, etc. When I use Epiphany (while they're less slimy or Google-connected than MozillaCo is), I'm much more visible to Google (and friends) overall.
Posted Aug 10, 2009 19:00 UTC (Mon)
by sbergman27 (guest, #10767)
[Link] (2 responses)
The adblocker uses filterset.G and now has an editor for the blacklists and whitelists.
And just as a tidbit that I learned about not long ago, when you specify a bookmark in the bookmark bar, you can define it with something like:
Title: Google
and it will appear in the bookmark bar as a text entry field. Customize to taste.
Posted Aug 10, 2009 19:09 UTC (Mon)
by jordanb (guest, #45668)
[Link] (1 responses)
It's still missing the functionality of customize-google though. Specifically, the ability to anonymize the google cookie, and block analytics.
Posted Aug 10, 2009 20:02 UTC (Mon)
by sbergman27 (guest, #10767)
[Link]
I should note that I have never used Greasemonkey or written an Epiphany extension. But I felt I should mention the options anyway.
Posted Aug 10, 2009 16:19 UTC (Mon)
by sbergman27 (guest, #10767)
[Link] (5 responses)
Posted Aug 10, 2009 17:14 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
It's also important to note that Mozilla is trying to figure out how to walk the line with regard to web services and data privacy.
http://www.mozilla.com/en-US/legal/privacy/firefox-en.html
The text on the third-party services page gives an indication that someone in the Mozilla fortress is thinking about privacy as it relates to integrated web services and the role of service partners play there. Would Canonical post the same sort of thing once they integrate default 3rd party services? Probably. The existing UbuntuOne and Launchpad privacy policies aren't particular different than the yawn inducing boilerplate that mozilla has for its website privacy policy. But is this sort of privacy notification enough? If a 3rd party breaches whatever agreement they have with Mozilla concerning data correlation what is the remedy to an end-user?
The issue of data privacy and terms of service notification in a social desktop context where a diverse set of web services are going to be interacting to provide functionality is going to be a very hard and complex issue. And most likely a moot one unless the very small minority of people who really care about data privacy figure out a way to get the much larger majority of web services users to start taking notice.
Something like the use of a specialized search page is just the tip of the iceberg of what you could get upset about. There's really nothing stopping any website you contact or interact with from sharing (and selling) its website access logs including details about ip addresses.
-jef
Posted Aug 10, 2009 19:26 UTC (Mon)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Aug 10, 2009 19:39 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
-jef
Posted Aug 10, 2009 21:19 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Aug 10, 2009 22:27 UTC (Mon)
by dlang (guest, #313)
[Link]
they are selling page impressions (advertising)
yes, the act of rendering the page tells the servers that are being queried what you are looking for, and your IP address because that's the way the Internet works (it may also send a cookie if you leave them enabled, which may let them correlate your queries more precisely than they could just with the IP). it's not clear at this point that your IP address can/should be considered private information.
selling access to your eyeballs is something _very_ different from gathering your personal info and selling that.
Posted Aug 13, 2009 3:30 UTC (Thu)
by akumria (guest, #7773)
[Link] (1 responses)
Part of the problem here is that Canonical completely screwed the user experience.
I would previously use Google, via the search bar, and have useful results.
With multisearch, I would use Google and get garbage.
Posted Aug 13, 2009 12:42 UTC (Thu)
by beuno (guest, #44010)
[Link]
Posted Aug 7, 2009 23:42 UTC (Fri)
by ewan (guest, #5533)
[Link] (2 responses)
The biggest problem here isn't necessarily the extension itself, it's the attitude that leads someone to think that this sort of behaviour is acceptable in a community. Canonical's approach is increasingly like that you'd expect from a proprietary software company.
Posted Aug 8, 2009 9:57 UTC (Sat)
by Cato (guest, #7643)
[Link]
Posted Aug 14, 2009 17:27 UTC (Fri)
by spitzak (guest, #4593)
[Link]
I in fact turned on that other Ubuntu checkmark (I think it is part of Synaptic?) to indicate that I can allow them to collect statistics on something (what software I install?). I don't have a problem with this but it is nice that there is an opt-in and it is off by default. I see no reason why they did not do the same thing with this.
Posted Aug 7, 2009 23:51 UTC (Fri)
by MattPerry (guest, #46341)
[Link] (64 responses)
Packaging the applications as part of the distro is great for newbies who want a controlled environment and experience à la Apple. Packages are mostly irrelevant to linux experts who want to do their own system administration and are happy to compile and install applications themselves. But for power users like me that are in the middle of that spectrum, they have to choose between the two extremes. I administrate systems and compile software all day long at work. I don't want to have to do it when I come home as that's time I won't get to spend with my family. At the same time, I don't want to have the versions of applications dictated to me by my distro.
It sucks when I upgrade my Ubuntu system to the latest release and it upgrades all of my applications to new versions even if I didn't want it to do that. The inverse is also true. Just because I want to stick with a "long term stable" release of Ubuntu doesn't mean that I don't want to upgrade my music player or OpenOffice to the latest version.
It's disheartening that the community isn't addressing this issue. Maybe it's just me and I'm the only person who desires the separation of maintaining the OS from maintaining the apps that other operating systems enjoy. When using a linux distro for my desktop, I miss the convenience of downloading an installer for the version of my choice of an app, clicking on the icon, and installing it. If we could reach that point then the drama that spawned this LWN article likely wouldn't have even occurred.
Note: I know each distro has different libraries and there are different architectures, but the linux community is really good at solving technical problems. I don't see that as something that can't be overcome. Also, if you're planning on posting an immature comment such as "Maybe you should ask your vendor for a refund," there is a story at Slashdot on this same Ubuntu issue where you can post such comments. I'd rather have an adult discussion here on LWN about the merits of this issue, or lack thereof.
Posted Aug 8, 2009 0:48 UTC (Sat)
by ms (subscriber, #41272)
[Link] (11 responses)
I broadly agree with the gist of what you're saying, which is that self-compiled packages and prebuild binaries don't mix in a system. I think that's not enormously related to this article though.
Posted Aug 8, 2009 3:11 UTC (Sat)
by MattPerry (guest, #46341)
[Link] (10 responses)
I disagree. This entire problem exists because there is a middleman between the software vendor, Mozilla, and the end user. Only those with significant technical knowledge can successfully circumvent that middleman. Finding a way for users to easily bypass the middleman without being a linux expert will eliminate these problems in the future.
Posted Aug 8, 2009 9:20 UTC (Sat)
by ikm (guest, #493)
[Link] (6 responses)
Posted Aug 8, 2009 15:33 UTC (Sat)
by MattPerry (guest, #46341)
[Link] (5 responses)
Right, so why is Ubuntu shipping that binary rather than leaving it up to the user to get it for themselves?
Posted Aug 8, 2009 17:25 UTC (Sat)
by ikm (guest, #493)
[Link]
Posted Aug 10, 2009 0:35 UTC (Mon)
by ringerc (subscriber, #3071)
[Link] (1 responses)
If there's a security hole in libpng, on a distro-shipped app all you need to do is update one package. If you're using vendor-supplied packages you need to find out which of your apps are affected and manually update them.
Why not share a common libpng, you ask? Well, in the case of libpng that's not unreasonable, but not all libraries have strong API/ABI compatibility guarantees. One app may need version 1.1 and another needs version 1.2.
OK, so parallel install the libraries. Sounds ok, right? Well, it does until you realize that the 1.1 and 1.2 libraries are _both_ linked into one process via a 3rd-hand library dependency, and everything falls in a heap. To work around this you need strict symbol versioning, and even then it's far from reliable.
I see two ways to tackle app distribution. One way is for the app to be completely self-contained, including all dependencies not part of the OS its self. This results in bloated installs (lots of duplicate libraries and data), security problems, app compatiblity problems ("DLL Hell"), memory bloat (DLLs/shared libs can't be shared in memory between different apps) and all sorts of other issues. If some rules are very strictly followed it can work, as Microsoft Windows proves. Ever packaged an app for Windows, though? It's not fun. Coding for the platform is also more complex: you must, for example, never assume that other DLLs are using the same C runtime as you, so you can't free() memory they've malloc()'d or vice versa, you can't pass a FILE* between DLLs, etc etc.
The other way is to ensure that the OS has a way to provide all dependencies in a central way, so apps don't carry them at all. To make this work practically the OS has to be responsible for app packaging and installation too, as it's hard to guarantee perfect compatibility of all libraries across distros especially given the problems with multi-versioning. This means that the app user is somewhat dependent on the OS to provide updated versions, but allows the OS vendor to ensure app compatibility and stability, eliminate shared library conflicts, etc.
I don't think either approach is "right" ... and personally, I wouldn't mind seeing improved distro compatibility in package formats, package names, etc so a package could be produced that'd reliably install on multiple distros. Sometimes, though, the package simply _couldn't_ be installed due to library versioning conflicts, so you'd still have to maintain a couple of versions or start bundling your libraries.
It's not a simple problem, and all the current solutions kind of suck.
Posted Aug 10, 2009 6:29 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Aug 10, 2009 10:02 UTC (Mon)
by dunlapg (guest, #57764)
[Link]
Re the "middleman", I definitely feel like the "middleman" is a feature. Look at all the crap that Windows users end up installing because there is no middleman! Because there's no one vetting the software and making sure that it's up to snuff, each individual piece of software wants to at least install its own update-checker and its own useless piece of junk in your status bar, if not its own spyware. With Ubuntu, they can have a reasonable policy across the board for that stuff, and as a result, my Ubuntu desktop is always more clean and usable than my Windows desktop. Even with the current "spyware" issue, I trust Ubuntu a whole lot more than I trust all those random "application providers" that might want to install who-knows-what on my system.
As someone else has already pointed out, Google and Mozilla both know everything that Canonical would know anyway. And after taking some business classes, I can sympathize with wanting to understand what your users are doing so that you can serve them better. (Asking is of limited use, because only certain kinds of people answer, and even when they answer, it may not be representative.)
My main concern is that new versions of Ubuntu not end up like a new Dell box, packed full of junk that I have to un-install before it's remotely useable. That's one of the things that I *really* appreciate about Linux distros: not having to deal with random junk.
Posted Aug 21, 2009 21:25 UTC (Fri)
by sigra (guest, #57156)
[Link]
...using wget I assume?
Posted Aug 8, 2009 19:18 UTC (Sat)
by k8to (guest, #15413)
[Link] (2 responses)
If you're in an environment where you care about certain things a great deal, then yes cut the middleman out of those things, as far down as you need to. If that means no longer using a distribution at all, or moving to another platform, so be it.
For typical medium shops, the middleman feature can make "the rest" of the system work fine with better quality and less effort.
For smaller shops, the middleman feature can be used everywhere.
Of course, if the middleman becomes untrustworthy, get a new one.
I could point to literally *hundreds* of times that the middleman has made my use of software vastly more pleasant than simply acquiring the software from the creator. I can point to about 2 where it has gone the other way.
Posted Aug 8, 2009 23:16 UTC (Sat)
by foom (subscriber, #14868)
[Link]
Posted Aug 10, 2009 11:26 UTC (Mon)
by iq-0 (subscriber, #36655)
[Link]
Posted Aug 8, 2009 2:10 UTC (Sat)
by drag (guest, #31333)
[Link] (23 responses)
Instead of it being:
It should really be:
./conifgure
For example take a mundaine example like 'gnome-games'. You have OpenSuse, Redhat, Debian, Ubuntu, Gentoo, etc etc.
So you have the 'gnome-games' source code associated with Gnome 2.24.
Each distro has to individually package, build, and troubleshoot the packages. There is subtle and rather insigificant implementation details that makes it difficult to track bugs and work together to create better software. And each distro has to re-do all the work that every other distro does.
So with OpenSuse, Fedora, Debian, Ubuntu, and Mandriva... Assuming that they have one person in each originization that is in charge of maintaining 'gnome-games' you have 5 individuals doing the same packaging with the same software versions with the same goals and are aiming for the same potential audiance.
That's 500% more work then it takes to produce a installer for Windows. And it doesn't really make sense. For every 1 man-hour that is needed to get software packaged you waste 4 man-hours re-doing all the same work.
That's 4 units of wasted effort for ever 1 unit of real work done. That's 4 units of time and money and effort that could go into bug squashing or improving documentation or working on some other peice of software.
And, ironically, it's those binaries produced for Debian vs Ubuntu vs Fedora, etc etc... all are compatible with each other.
When people like Opera produce proprietary software for Linux they have dozens and dozens of packages for each distro.... but actually if you look at the checksums on the binaries and library files they install it's all identical. Opera installs the same exact hunk of software on every distro, except very old ones (and that is due to the C++ ABI breakage from years ago).
So it's mostly just stuff as silly as versioning numbers and how large projects are carved up into smaller packages that are causing incompatibilities.
Posted Aug 8, 2009 2:19 UTC (Sat)
by drag (guest, #31333)
[Link] (5 responses)
Really Debian needs Ubuntu and Ubuntu needs Debian.
They have to work together. It's reality.
Ubuntu could not exist without the high quality packages that Debian produces. It would be _impossible_.
And Ubuntu is able to provide something that Debian so far has failed utterly... Make a friendly Linux desktop. Debian _can't_ do it. I don't know why. But they can't.
And I actually prefer Debian over Ubuntu for my desktop. Compared to Fedora or Ubuntu the Debian desktop experience is nothing but a huge PITA. It takes about 4-5 hours of nerd work to make their Gnome stuff as usable as what I can get from Fedora in 10 minutes.
I can't even get PA to work properly for me. The volumes controls for Gnome and Compiz and all that are all goofed up. I don't know what to do to fix it. With Fedora it was just right.
Debian needs Ubuntu for that sort of stuff.
Posted Aug 8, 2009 3:03 UTC (Sat)
by srivasta (guest, #7075)
[Link] (4 responses)
What does Debian gain from _other_ operating systems having an (allegedly) friendlier desktop anyway?
Posted Aug 8, 2009 7:01 UTC (Sat)
by tajyrink (subscriber, #2750)
[Link] (3 responses)
Posted Aug 8, 2009 7:34 UTC (Sat)
by drag (guest, #31333)
[Link] (2 responses)
There is more to getting a good dekstop then just doing the 'make install'. A userfriendly desktop must provide all-working functionality as well as the normal set of expected functionality.
Something like that. It's a total package thing. Just providing working software is a first step.
-----
The trick is that whatever it takes Debian hasn't been able to do it. If Debian had the ability to get good default configuration out to users on a timely basis then there would of never been any need for Ubuntu in the first place. There would of been no market for it... people would of just used Debian.
Posted Aug 9, 2009 17:15 UTC (Sun)
by srivasta (guest, #7075)
[Link] (1 responses)
Part of the so called improvements in the desktop have been pruning away of choices presented to the user. Instead of 23 MUA's, ship 3. Who gets to decide which 3? Why, your distro overlords, of course. The other part consists on streamlining the distribution down to a couple of thousand packages, relegating the rest to a non-core multiverse. However, the former is the probably the major reason for the popularity: when one removes choices, and makes decisions on behalf of the end user, one can offer a slick presentation -- as long as you like the decisions made; and most people usually do not care.
Debian went the direction of choices, allowing people to tailor the distribution to their liking. This makes for more questions, and perhaps more configuration choices, and perhaps, confusion for the novice. But one is only a novice for so long, annd I am glad that the easier shoices prof erred by Debian exist.
If there is a way of creating something that is slick _and_ manages to offer the choices, I think Debian folk would be happy to hear about it.
manoj
Posted Aug 11, 2009 17:03 UTC (Tue)
by kov (subscriber, #7423)
[Link]
Posted Aug 8, 2009 14:45 UTC (Sat)
by dwheeler (guest, #1216)
[Link] (5 responses)
I agree in principle that a source code install should work with the package manager (so that you can easily remove it later, upgrade, know what you're getting, etc.). And behind-the-scenes, the list of operations seems reasonable in principle.
But what is needed is a trivial point-and-click interface that auto-configures, makes, and installs (working with the distro package manager). One that works well enough automatically so that people don't NEED to read the README file to install it the "usual" way.
If
developers would simply follow the standard conventions for source distribution, this would work well; it'd be even easier with
software that would
automate DESTDIR (I intend to release software soon to do the latter).
That wouldn't solve all the problems (in particular, there need to
be conventions so that dependencies are downloaded and installed),
but that would help.
Posted Aug 8, 2009 17:39 UTC (Sat)
by nix (subscriber, #2304)
[Link] (3 responses)
One point though. You said:
Posted Aug 9, 2009 1:35 UTC (Sun)
by dwheeler (guest, #1216)
[Link] (2 responses)
Nice paper.
Thanks.
You forgot the horror which is libtool. That runs the compiler at install time to do a link, so you have to wrap the linker! You may get away without wrapping it if it turns out that it always asks the compiler to put things in the srcdir, and then uses 'install' to move them out.
Ah, libtool.
Well, I'm definitely aware of libtool; I wrote the
Program Library HOWTO, after all.
But from what I've seen, someone who uses libtool will typically support DESTDIR as well (I speculate that if you're a libtool user, you're probably more interested in portability and thus more likely to support DESTDIR).
And even if that's not true, my current approach can accommodate it anyway.
I've ended up deciding that to automate DESTDIR, it's best to simply create "wrappers" of the same name and put their location at the front of the PATH. It seems hackish, but it has absolutely NO security issues, and it runs really quickly. Which means that it is more likely to actually be ACCEPTABLE to distros and users. I haven't tried to wrap libtool (yet), but I think that should work well if it turns out to be necessary. I've already wrapped cp, ln, and so on, and tried them out on several test programs without problems.
Posted Aug 9, 2009 10:26 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Aug 17, 2009 18:25 UTC (Mon)
by dwheeler (guest, #1216)
[Link]
By the way, my "Auto-DESTDIR" program has now been released at
http://www.dwheeler.com/auto-destdir - it supports DESTDIR in source installs, even when the original makefile doesn't support DESTDIR. One you have Auto-DESTDIR install, just run make-redir instead of make when you do an install. I.E., use "DESTDIR=... make-redir install" instead of "make install".
Posted Aug 9, 2009 14:07 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
In short, you need a PACKAGE system. So back to square 1.
Posted Aug 8, 2009 15:46 UTC (Sat)
by MattPerry (guest, #46341)
[Link] (3 responses)
Yes, exactly.
> ./conifgure
That's a great idea. If that could be reduced to an action that happens when someone double-clicks on an installable package then it would be ideal.
> For every 1 man-hour that is needed to get software packaged you waste 4
I thought that the Linux Standards Base was supposed to make it so that LSB compliant binaries would work on LSB compliant distros. If more effort was put into LSB compliance from the distro and application providers maybe we could achieve single-click installation and execution for applications. It would be a win for end-users and for the distros too as they wouldn't spend the time duplicating work.
Posted Aug 8, 2009 19:15 UTC (Sat)
by drag (guest, #31333)
[Link] (1 responses)
Different standards organizations work in different manners. For example Freedesktop.org has it's XDG stuff which is 'next gen' (when it was developed). This has added considerably in helping users experience consistent behavior and addressing many of the annoyances that come from having different desktop environments.
A big example is previous to things like "xdg-open" application developers that wanted to call a seperate browser for documentation or linking online had to hardcode it into their installation scripts or in their applications. The best they could do was to allow people to go into their application preferences and set a default browser. Most people just hardcoded 'mozilla' since that was the premiere browser at the time.
Obviously this is less then preferable. Either forcing everybody to use 'mozilla' or forcing everybody to configure a browser for each and every application that happened to need to call a browser.
LSB is a bit different though. They are a 'best practices' type orginization that goes and finds what is consistent and supportable across all distros and then formalizes it. The amount of stuff that LSB tries to impose on distros is relatively small and distros tend to respond very negatively when they do (like standardizing packages to be RPMs and forcing some new directory structure).
So they don't assume a position of making people work together. Their position is much more centered aorund documenting and making formal in what ways they already do that. So that when you have third party developers (ISVs) or you have people new to Linux then they have a place to go to learn what parts of "Linux OS" they can depend on.
So things that cause incompatibility and problems for developers who try to target multiple distros that LSB doesn't cover should be mostly because distros refuse to work together about those things. It's not LSB's position to try to force those sort of issues.
Traditionally the biggest problem is going to be because of GUI applications. The 'GNU' part in 'GNU/Linux' is very consistant normally, but the differences in how people setup KDE vs Gnome vs Whatever causes all sorts of headaches.
------------------
The latest thing that LSB is trying to deal with is the GUI applications through the Moblinv2 specifications developed by Intel.
This is only targeting smaller devices, but I am hoping that it will extend to desktops and workstations.
Moblin dictates that you need to have a Gnome-based environment and that you have all the dependencies that it says you should have for it. It includes specific libraries and specific versions of libraries. It also assumes that if you have newer then the specified libraries then those libraries should be backwards compatible with the versions that it dictates. It has bunches of PDFs outlining all of this, plus test cases and a certification process.
So far it seems that Novell, Ubuntu, and Fedora are releasing Moblin compliant versions of their operating distros, as well as smaller custom-commercial companies like Xandros.
--------------
the main problem with Moblinv2 is that it's more for smaller devices, but I am hoping that it'll be move 'up' and include desktops and workstations. It's heavily influencing the direction of Gnome 3.0 I believe.
The other big problem is that it's very Gnome centric and thus KDE fans and people who care about older and slower devices will have a tendency to dismiss it early on.
My thoughts on this goes like this:
Gnome stuff, while heavy in nature when running, does not really take up that much disk space. Thus the price you pay for Moblin compatibility is rather low. Even old computers should be handle the additional disk space required without blinking.
And what gets you is a solid and constant base for users to build off of.
----------------------------
I learned this when dealing with OpenLDAP.
People have, in the past, had huge issues learning LDAP with OpenLDAP. There is a wealth of documentation and examples on LDAP, but very little actually covers the initial setup and deployment of OpenLDAP. When you install OpenLDAP from Debian and Fedora it's built correctly, but it's a blank canvas...
So users will read the documentation and want to experiment with OpenLDAP, but the initial setup to get a actual working example is a very high barrier and they get confused and dismayed and usually give up.
So if they were given a nice default setup, even if it wasn't what they needed ultimately then it makes things MUCH easier to learn and deploy and would increase the value of the software by a large amount.
This is the advantage that companies get with Microsoft Small Business Server setup. Everything is designed to work together by default. Even if SBS is not a good match for the company initially then having a consistent and working basis (as well as documentation) is invaluable to build off of and modify so that it does end up being a good match.
------------------------
Linux desktops and desktop application development is not like that. There is no solid basis, no solid and constant foundation.
It's like walking on shifting sand... everything is moving around under your feet. People get the feeling that they are building a house on wet clay... no matter how well and how strong you build your house if the foundations are not done correctly and are not consistent then your screwed. The more you effort/time/money you spend on it the worse off you are.
If users and developers are presented with a solid, working Desktop, that has all the basic features and services done correctly and is working then that makes using and customizing the desktop much easier. Even if 'Moblin' or 'Gnome' is not what they want, having that solid working base to fall back to and build off of makes things much much easier.
What is the fun in getting Awesome WM configured and all EXCELLENT if you have to struggle around with Pulseaudio or Alsa and need to compile patches in Network-Manager (or uninstall it entirely) to get basic OS features working correctly?
With everything 'working by default', then developers only have to worry about the stuff they care about. They don't have to worry and care about things that they don't want care about and don't have in-depth knowledge about.
--------------------------
'Usable By Default' is along the same lines as 'Secure By Default'.
When a user installs a secure OS like OpenBSD or Debian's 'base install' it has almost no chance of providing what the user wants ultimately. They want a network router or a web server or email server or something like that.
However what it gets you is that you can deploy a HTTP server without having to worry about SNMP security and SMTP security and SMB security and NFS security, etc etc. etc. You only have to concentrate on the stuff you need to concentrate on and you still end up with a secure system.
---------------------------
Like if I am developing a video game using Blender.. Idon't want to care about sound APIs. I don't want to have to worry if PulseAudio or Alsa or OSS is being used. I don't want to worry about if the users have the ability to connect to wireless networks correctly for playing multiplayer or if they have a decent browser that is compatible with my documentation. I don't want to worry about if their distro has a good MESA implementation or if the user is using proprietary drivers or if the user does not know that they need drivers installed at all. I don't want to care if they have the ability to full-fill the python requirements or have goofed up python libraries all the time.
If I have to worry and deal with every little detail with the desktop and have to provide work-arounds and documentation and support for every little thing that can screw my game up... then I won't have any time to make the actual game!
Posted Aug 12, 2009 4:15 UTC (Wed)
by TRS-80 (guest, #1804)
[Link]
So users will read the documentation and want to experiment with OpenLDAP, but the initial setup to get a actual working example is a very high barrier and they get confused and dismayed and usually give up.
So if they were given a nice default setup, even if it wasn't what they needed ultimately then it makes things MUCH easier to learn and deploy and would increase the value of the software by a large amount.
Posted Aug 9, 2009 17:20 UTC (Sun)
by srivasta (guest, #7075)
[Link]
By far the most impressive bit of Debian is the Technical policy manual, and how the packages create a more integrated whole by following the dictum of policy (which, BTW, is not a statid dead set of rules, but a vibrant, breathing, changing document). Very few upstream packaged software pays much attention to it, as can be seen by running lintian -vi on the packages produced.
manoj
Posted Aug 10, 2009 0:42 UTC (Mon)
by ringerc (subscriber, #3071)
[Link] (5 responses)
That looks good in principle, but tends to break easily when faced with different apps requiring different versions of libraries that don't maintain ABI compatibility. You can change the soname, but you're still in trouble if you encounter a linkage chain like: Symbol versioning of libx can help, but doesn't seem to solve all the issues.
Posted Aug 10, 2009 11:21 UTC (Mon)
by mjthayer (guest, #39183)
[Link] (4 responses)
Posted Aug 10, 2009 18:53 UTC (Mon)
by nix (subscriber, #2304)
[Link] (3 responses)
What RTLD_LOCAL fixes is the 'whoops, symbol name clashes between totally
Posted Aug 10, 2009 19:08 UTC (Mon)
by mjthayer (guest, #39183)
[Link] (2 responses)
Posted Aug 11, 2009 9:22 UTC (Tue)
by ringerc (subscriber, #3071)
[Link] (1 responses)
That makes it hard when libraries at the same linkage "level" (say libh and libi) want to pass around objects that may, either overtly or behind the scenes, rely on shared static data (library-internal caches or the like) in a library (say libj) they both use. Of course, they can't pass libj objects across library boundaries anyway unless they know they're using at least a compatible version of libj, since their layout might and/or meaning not be compatible, so they may as well share the same instance of libj's rw data segment too, as if it were RTLD_GLOBAL.
This sort of thing is very common in things like application frameworks (qt/gtk/etc) and plugins.
I seem to remember that Mac OS X tackles this by defaulting to something like RTLD_LOCAL linkage, but allowing objects to specify global linkage instead. That's vague memory only though, and I haven't hunted down any documentation to confirm it.
Posted Aug 11, 2009 9:34 UTC (Tue)
by mjthayer (guest, #39183)
[Link]
Posted Aug 10, 2009 8:13 UTC (Mon)
by mjthayer (guest, #39183)
[Link]
I would suggest a slight correction to your assertion. At least for "true" FOSS applications, the ultimate solution might be for the distribution packagers to work directly on the upstream code base instead of on a distribution fork. The upstream code base would then support your "make rpm", but it would be Redhat/Fedora/SUSE/whoever who would actually run that to create the packages. And the distributino packagers would then have the additional task of monitoring the changes made by packagers for other distributions and making them harmonise (or at the very worst adding upstream "#ifndef FEDORA"s and suchlike) with their own needs, and making sure that upstream versions branches fit in with their own versioning requirements
Posted Aug 8, 2009 2:20 UTC (Sat)
by ldarby (guest, #41318)
[Link] (8 responses)
Also, I subscribed to lwn just for this article :)
Posted Aug 8, 2009 8:56 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link] (7 responses)
It is a program that has been unmaintained for years. It is based on gtk1.2 which is likewise unmaintained.
Posted Aug 8, 2009 9:48 UTC (Sat)
by jengelh (guest, #33263)
[Link] (6 responses)
- xmms2: do any of the clients provide me with the traditional winamp/xmms1 interface and skin support?
So, back to xmms1.
Posted Aug 8, 2009 9:51 UTC (Sat)
by jengelh (guest, #33263)
[Link] (5 responses)
network stream:
alsa:
Posted Aug 10, 2009 12:25 UTC (Mon)
by SEJeff (guest, #51588)
[Link] (4 responses)
Posted Aug 10, 2009 12:30 UTC (Mon)
by jengelh (guest, #33263)
[Link] (3 responses)
Posted Aug 10, 2009 12:36 UTC (Mon)
by SEJeff (guest, #51588)
[Link] (2 responses)
Posted Aug 10, 2009 21:34 UTC (Mon)
by k8to (guest, #15413)
[Link]
Posted Aug 10, 2009 22:18 UTC (Mon)
by jengelh (guest, #33263)
[Link]
Posted Aug 8, 2009 2:23 UTC (Sat)
by smoogen (subscriber, #97)
[Link] (2 responses)
Posted Aug 8, 2009 15:57 UTC (Sat)
by MattPerry (guest, #46341)
[Link] (1 responses)
The Linux Standard Base was supposed to fix this. From what I'm told, it didn't, for reasons I do not know. I still think that fixing the problems with LSB and providing a way to audit distros for LSB compliance will allow application vendors to target an binary package to a particular LSB standard which would work on any LSB compliant distro of the same LSB version.
Posted Aug 8, 2009 18:31 UTC (Sat)
by lmb (subscriber, #39048)
[Link]
Distributions aren't as much of a problem as this discussion makes them out to be.
Posted Aug 8, 2009 7:18 UTC (Sat)
by cuboci (subscriber, #9641)
[Link] (6 responses)
That's like saying upstream doesn't make mistakes and all bugs are introduced by distributors. Just think of all the security holes distributors patch before any upstream developer even takes notice of them.
Also, I wouldn't trust upstream developers to package software correctly for the distribution I use unless all distributions are the same - in which case there wouldn't be any. And just look at the state of software packaging on Windows. Same base for all, no package management that deserves the name.
Distributors only providing a base and upstream developers packaging the software themselves (which is a lot of work, btw!) would probably lead to something similar.
Posted Aug 8, 2009 16:59 UTC (Sat)
by MattPerry (guest, #46341)
[Link] (4 responses)
It's not like that at all. Each person who modifies the code increases the chance of introducing errors. I'd prefer that the developers of the software review the patches that go into a program I use. Mistakes will still happen, but at least a process is in place where the people who know the program best can review what goes into it.
The Debian SSH problem is a great example. The packager did seek feedback from the OpenSSH team about their change and was told it was okay. But they continued to make further changes to a similar piece of code that introduced a security issue. Had that additional change been reviewed by the original developers, the chance of it being caught would have been increased.
> Just think of all the security holes distributors patch before any
That sounds like a communication problem.
* Why did the distro packager not notify the upstream developer of the problem and coordinate a fix?
If multiple distro packagers know about the problem and are applying the patch, you are then duplicating work among distros. See drag's comment above about all of the effort that is duplicated and wasted between distro packagers doing the same task over and over.
> Also, I wouldn't trust upstream developers to package software correctly
I'd trust them to package things if we created standards and processes to make packaging easy for them. The Linux Standard Base is supposed to provide such a standard. Maybe we as a community need to revisit such standardization and bring pressure upon distros and application providers to properly conform to said standards.
> And just look at the state of software packaging on Windows. Same base
Windows' package management may pale in comparison to what Linux-based package systems provide, but it's far from broken. From an end-user perspective, it may be simple but it works. For example, I can download Firefox or OpenOffice from the developer's web site and use the same package to install on a variety of Windows versions without issue. Removing a package is equally easy and problem free.
> Distributors only providing a base and upstream developers packaging the
Plenty of open source and free software vendors successfully package and distribute working install packages of their software for Windows and they install, work, and can remove flawlessly.
Examples: Cygwin, OpenOffice, Vuze, Firefox, CDex, Calibre, Pidgin, VirtualBox, Vim, Emacs, XEmacs, OpenVPN, GIMP, VLC Media Player, Audacity, Scribus, Ekiga, AbiWord, Apache, PHP, PostgreSQL, MySQL.
So they can successfully do this for Windows but doing the same for Linux distros is somehow not possible? I don't believe that for a second.
Posted Aug 9, 2009 10:29 UTC (Sun)
by dtucker (subscriber, #6575)
[Link] (1 responses)
The incident I think you're referring to (http://lwn.net/Articles/282038/) was a change to OpenSSL, not OpenSSH. OpenSSH was impacted because it uses OpenSSL's RNG functions but it wasn't the location of the change in question.
Posted Aug 11, 2009 14:46 UTC (Tue)
by MattPerry (guest, #46341)
[Link]
Posted Aug 10, 2009 0:52 UTC (Mon)
by ringerc (subscriber, #3071)
[Link] (1 responses)
FF, OO.o, etc work on Windows because they bundle every dependency directly into the app download. They each maintain private copies of libpng, libjpeg, gtk, etc etc etc. These libraries cannot be shared in memory and use extra disk space. Who cares these days, right? However, the separate libraries mean that the app vendor must issue a security update if any of the libraries they use in the app suffer from a security hole. Each vendor must update its app(s) separately, since they have private copies of the affected libraries. The poor user has to find out about these updates - or is deluged with hard-to-verify-as-authentic update dialogs from a bunch of different apps. App auto updates are dangerous when the user has no way to verify that (say) the OO.o update dialog really is from OO.o, not a web page trying to trick them into downloading malware. I've already seen fake Adobe Updater dialogs, so this is far from a theoretical problem. To you or I it might seem fairly obvious how to check, but most users just haven't the foggiest, and tend to either reject all updates (leaving their machine with gaping security holes) or accept them all (opening them to malware risks). FF works around this by not giving the user a choice. That's fine so long as the updates are trivial, you're absolutely certain they'll never break anything, and the user has the access permissions to actually install the updates. The latter, however, is often an issue in FF installs, and tends to leave users confused. An OS-provided central secure update channel would help mitigate these issues. Think "Microsoft Update" but with 3rd party providers allowed to subscribe their apps. This would put MS in the implied position of being expected to vet all those updates, though, and they're never going to allow it. WHQL drivers already give them quite enough trouble. As if the security issues weren't unpleasant enough, there's also the fun of "DLL hell" or "shared library hell" caused by ABI-incompatible libraries with the same soname being loaded into the one executable. This would seem trivial to avoid by bundling all your own libraries, and these days _mostly_ is, but you still run into unpleasant issues with LoadLibrary/dlopen(), user PATH / LD_LIBRARY_PATH settings, etc. Essentially: Yes, the Windows app distribution model works, but it (IMO) suffers from a collection of annoying flaws just like the Linux distro model. They're just different annyoying flaws.
Posted Aug 10, 2009 16:26 UTC (Mon)
by Cato (guest, #7643)
[Link]
Posted Aug 10, 2009 11:28 UTC (Mon)
by mjthayer (guest, #39183)
[Link]
Posted Aug 8, 2009 7:46 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link]
Linux distributions had to deal with a misbehaving upstream. This should be an interesting test-case for you.
I'm also a proud user of the Debian package mozilla-noscript . The Debian packager there has kept me from the mis-behavings of upstream.
Posted Aug 8, 2009 9:47 UTC (Sat)
by coriordan (guest, #7544)
[Link] (1 responses)
In the 90s, when I used a proprietary OS, the default video player played all videos. Then I'd install QuickTime, and it would impose itself as default video player plus default image viewer despite it's image viewing capabilities being awful. Then I'd install RealPlayer, same problem again. One would do this via the registry, another would do it via start-up programs, and others did it in ways I never got to the bottom of.
Then I moved to GNU/Linux. I can install ten video players, and they don't fight with each other. What a relief.
If everyone got their Firefox direct from Mozilla, and if the Mozilla developers were told to say nothing about a privacy problem, then who would have noticed the privacy problem? When distros modify packages, that introduces an independent review into the supply chain.
Posted Aug 8, 2009 11:48 UTC (Sat)
by jospoortvliet (guest, #33164)
[Link]
Posted Aug 8, 2009 17:34 UTC (Sat)
by TRS-80 (guest, #1804)
[Link] (2 responses)
Where do you draw the line between the OS and applications? Are perl and python part of the OS? GTK+, Qt?
You say it's a technical problem, but the technical side has been solved several times. Autopackage has been around for years and got approximately zero traction. I haven't changed my views on the utility of distributions since the last time this was discussed on LWN so I won't repeat myself.
Posted Aug 10, 2009 11:31 UTC (Mon)
by mjthayer (guest, #39183)
[Link]
Posted Aug 12, 2009 0:15 UTC (Wed)
by MattPerry (guest, #46341)
[Link]
Yes, but the choice of backports is extremely limited. Taking at look at the backports for Ubuntu 9.04 (http://packages.ubuntu.com/jaunty-backports/allpackages?f...), there are only a handful of files. One is left hoping that an experienced developer will backport your application of choice. If all applications were backported then it wouldn't be a problem.
For example, I use an ebook management program called Calibre. The version in the latest Ubuntu is 0.4.143. There have been more than 22 releases of Calibre since that time including two major revisions. The version in Ubuntu has tons of bugs that have since been fixed. Where's the backport?
Not even Firefox 3.5, which is a very popular application, has been backported. When googling about installing FF 3.5, the suggestion from everyone is to download it from the vendor's web site. If that's the best solution, why aren't we facilitating that on a larger scale right from the beginning?
> Where do you draw the line between the OS and applications? Are perl and
My opinion is that if it's not part of the standard Gnome desktop and it's not needed to boot to the desktop, then it shouldn't be installed. If Perl and Python are not needed to get to that point, then they shouldn't be installed until they are needed. For that matter, Firefox should not be installed by default either. The Linux community loves to point fingers at Microsoft for bundling Internet Explorer with Windows, yet linux distro providers do the same thing with Firefox. There are other browsers for Linux than Firefox, and not everyone needs a browser. Any justification for including it can equally be used to justify the inclusion of IE in Windows, monopoly status or not. The same goes for all the other stuff that distros install (word processors, web cam programs, IM & email programs, games, drawing programs, etc).
> You say it's a technical problem, but the technical side has been solved
Then maybe it's a management problem. Maybe the community needs to work to find a way to provide application developers with the tools, methods, and information to allow them to create and distribute a single package that will install and work on all modern Linux distros. As an end-user, I don't find that goal to be unreasonable.
Posted Aug 10, 2009 17:21 UTC (Mon)
by davide.del.vento (guest, #59196)
[Link]
So let me try to understand what do you want.
a) you don't want to be "forced" to do what your distro does
So what? I don't see the third option! I think what you really want from your distro is the ability reading your mind, and doing what you'd like. But... wait a minute, this is what this post was about! So Canonical is right: if they study your behavior they might be able to do what you'd like!
About me, I'm really happy with 95% of Ubuntu LTS choices. For the rest 5%, I do download, compile and install outside Synaptic. I think it's a really great compromise: I don't want the hassle to manage security updates on everything, but the very few stuff that I need in "bleeding edge" release. I don't care if OpenOffice or Inkscape (which I do like and use) are not the lastest version!
Posted Aug 10, 2009 17:40 UTC (Mon)
by MattPerry (guest, #46341)
[Link]
Posted Aug 22, 2009 7:14 UTC (Sat)
by DarthCthulhu (guest, #50384)
[Link]
It really is wonderful.
Posted Aug 8, 2009 1:52 UTC (Sat)
by mattdm (subscriber, #18)
[Link] (5 responses)
Posted Aug 8, 2009 8:58 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link]
Posted Aug 8, 2009 9:52 UTC (Sat)
by coriordan (guest, #7544)
[Link] (3 responses)
Yes, it certainly is about time to move to IceWeasel or IceCat or Konqueror.
Posted Aug 11, 2009 5:10 UTC (Tue)
by roc (subscriber, #30627)
[Link] (2 responses)
Posted Aug 11, 2009 9:47 UTC (Tue)
by coriordan (guest, #7544)
[Link] (1 responses)
Many plugins have been written to protect Firefox users from having their personal info being collected by Google. If Mozilla put the users' interests first, it would include some of these plugins in their official version of Firefox. But they don't. Their top priority is getting funding from Google.
Further, they use their trademark policy to make it problematic for redistributors to add privacy features.
Users should choose the version of Firefox that serves their needs. Mozilla's official version is the weakest in terms of privacy protection, so users should avoid it.
Posted Aug 11, 2009 17:43 UTC (Tue)
by roc (subscriber, #30627)
[Link]
I don't know why you single Mozilla out, but it's irrational.
Posted Aug 8, 2009 2:30 UTC (Sat)
by torstenaf (subscriber, #58477)
[Link]
Ubuntu/Canonical need to be wary at this point. They have grown so large and popular, the signs are there that they are beginning to abuse their position. The first sign (to me) was supporting Android applications on Ubuntu when there are so many fundamental things that still need work. The second thing is this use-monitoring firefox extension.
I do not donate money to the Ubuntu project to be spied on.
Posted Aug 8, 2009 8:16 UTC (Sat)
by job (guest, #670)
[Link] (1 responses)
Posted Aug 10, 2009 14:13 UTC (Mon)
by hildeb (guest, #6532)
[Link]
Posted Aug 8, 2009 8:19 UTC (Sat)
by evaldas (guest, #12132)
[Link]
Posted Aug 8, 2009 9:33 UTC (Sat)
by coriordan (guest, #7544)
[Link] (11 responses)
Even if the data being collected by Ubuntu is only what was already being collected by Mozilla+Google, the users should have been notified so that they have the possibility to view Ubuntu's privacy policy for this data. Secondly, Mozilla isn't a good yardstick for privacy respect. Their income is almost completely dependent on Google and their deals as based on Google receiving masses of personal information about Firefox users. Many privacy protecting features and plugins have been written for Firefox, but Mozilla will never consider including them in Firefox because their income model is based on Google having access to all that personal info about Firefox's users. And if a GNU/Linux distro does include such features, Mozilla prohibits them from using the "Firefox" trademark. Very nasty altogether. People should not use any webbrowser called "Firefox". Use IceCat, or IceWeasel, or Konqueror, or another free software browser.
Posted Aug 8, 2009 9:46 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link] (10 responses)
Posted Aug 8, 2009 9:58 UTC (Sat)
by coriordan (guest, #7544)
[Link] (9 responses)
Where are the "Firefox" webbrowsers that include Tor anonymity plugins? Adblock plugins? Anonymised search plugins?
There are none because such configurations would reduce the amount of personal info being received by Mozilla's financial boss, Google.
Posted Aug 8, 2009 17:47 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (1 responses)
Posted Aug 10, 2009 8:18 UTC (Mon)
by regala (guest, #15745)
[Link]
hmmm, God bless you then...
Posted Aug 9, 2009 15:03 UTC (Sun)
by AndreE (guest, #60148)
[Link] (3 responses)
Are these addons rendered ineffective by some hardcoded usage sharing in Firefox?
Posted Aug 9, 2009 21:26 UTC (Sun)
by coriordan (guest, #7544)
[Link]
They work fine, and using them is a great idea. And because Firefox is free software, Mozilla can't prevent you from using them. The question is, why are these great plugins that protect user privacy not included in the default install? The answer is that Mozilla's funding comes almost exclusively from Google, and Google's business model is based on gather as much personal information about Internet users as possible.
Tech savvy users like you and I are fine, we install plugins or switch to other software, but our parents and children will mostly install Mozilla's Firefox without any plugins, and they won't benefit from any of the privacy protection which is widely available.
Posted Aug 10, 2009 15:12 UTC (Mon)
by nick.lowe (guest, #54609)
[Link] (1 responses)
Firefox just has its default homepage set to http://www.google.com/firefox
Most of Mozilla's revenue derives from traffic sent to Google at that
Posted Aug 12, 2009 2:26 UTC (Wed)
by k8to (guest, #15413)
[Link]
Posted Aug 9, 2009 17:36 UTC (Sun)
by tzafrir (subscriber, #11501)
[Link]
Posted Aug 11, 2009 5:20 UTC (Tue)
by roc (subscriber, #30627)
[Link] (1 responses)
So what on earth are you talking about?
Posted Aug 11, 2009 5:22 UTC (Tue)
by roc (subscriber, #30627)
[Link]
Using Google as the default search provider in Firefox gives Google no more "personal info" than if you did the search by visiting google.com *in any other browser*.
These claims that Mozilla configures Firefox to ship masses of personal information to Google are, as far as I can tell, false.
Posted Aug 8, 2009 12:08 UTC (Sat)
by ssam (guest, #46587)
[Link]
this sound like it will be fixed. it was done so that the ubuntu devs could see which part of the UI users used to search. thats fair enough.
a separate issue is the revenue from google searches. google earn money from searches by showing adds. if you help drive traffic to google, they'll give you a cut of that money. when you use upstream firefox and search google mozilla get the cut [0]. lots of websites do the same (try using boingboing.net's search). it seems fair enough that ubuntu should do the same. (i am supprised that their licence to use the 'firefox' name allows them to divert the search income, but thats for mozilla and canonical to work out).
one question is how much information does canonical get about the searches, do they get a list of IP address and search terms? if so were do we find the privacy policy. will they start showing targeted ads on the ubuntu websites? will they start showing targeted ads in the ubuntu interface? i guess not, but it might reassure people to have an official statement.
[0]http://www.pcworld.com/businesscenter/article/154198/goog...
Posted Aug 9, 2009 6:14 UTC (Sun)
by njs (subscriber, #40338)
[Link]
If I were a journalist, I'd probably connect this to the ongoing storyline that Ubuntu wants to do everything downstream (see also their new notification UI, session switching UI, etc.). Except here, not only are they diverting their own resources into making Ubuntu-specific improvements to Firefox's UI, they're also diverting user testing data and revenue that's currently going to Mozilla so that it goes to themselves instead. Mozilla doesn't have any inherent moral right to take Google's kick-backs over Ubuntu, but it's an interesting twist.
Posted Aug 9, 2009 10:29 UTC (Sun)
by akumria (guest, #7773)
[Link]
(much time spent, trying to find actual link)
http://www.google.com/coop/docs/cse/tos.html
Above is the closest match I could find.
Basically, it is OK for them to do this via a 'default homepage' but <em>NOT</em> via a software program (i.e. the search box).
I reported the issue to Google - but who knows if my message went anywhere interesting.
Totally annoying update, poorly justified, and poorly done.
Posted Aug 9, 2009 17:24 UTC (Sun)
by bronson (subscriber, #4806)
[Link]
Thanks to LWN for describing how to turn it off! My enjoyment of Karmic just went up 100%.
Posted Aug 10, 2009 9:18 UTC (Mon)
by christian.convey (guest, #39159)
[Link]
One big differentiator between Ubuntu and Windows is that with Ubuntu, I've always felt like the developers were on *my* side. That's huge.
With the attitude revealed by this stunt, they're are risk of losing that special status.
Posted Aug 22, 2009 17:28 UTC (Sat)
by muwlgr (guest, #35359)
[Link] (1 responses)
Posted Aug 22, 2009 20:29 UTC (Sat)
by dlang (guest, #313)
[Link]
Posted Aug 23, 2009 12:13 UTC (Sun)
by Thewolf40 (guest, #60404)
[Link]
Ease up a bit - The feature has already been taken out. And there's no vorries.
Ubuntu's multisearch surprise
If the user experience was damaged, then the developers learned a lesson, and can understand better what changes can be done.
Missing the point: it's about privacy
Missing the point: it's about privacy
Missing the point: it's about privacy
Missing the point: it's about privacy
Missing the point: it's about privacy
Missing the point: it's about privacy
Address: http://www.google.com/search?q=%s
Missing the point: it's about privacy
Missing the point: it's about privacy
Missing the point: it's about privacy
Missing the point: it's about privacy
http://www.mozilla.com/en-US/legal/privacy/firefox-third-...
http://www.mozilla.com/en-US/privacy-policy.html
Missing the point: it's about privacy
data protection laws are pretty strict and as of next April the
Information Commissioner will have power to levy quite substantial fines
for violation of that law. The UK *had* its privacy Chernobyl, and it
wasn't Canonical who triggered it, it was contractors working for the
taxman.
Missing the point: it's about privacy
Missing the point: it's about privacy
to transfer personal data out of the EU to an organization outside it (in
the US or elsewhere) unless that organization commits to following EU
regulations in this area: unfortunately, this is widely breached :(((
they are not selling user data
Missing the point: it's about privacy
Missing the point: it's about privacy
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
> that what you get there is essentially a precompiled binary. Untar it and
> run it.
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
you build your own copy, because FF relies on some patches that were
rejected by upstream. And FF ships NSS because, um, they were shipping NSS
many years before any Linux distros were using it for anything else at all
(and a good few still don't: its only real advantage is certification
stuff, and if you don't care about certifications GnuTLS has a far less
ugly interface and OpenSSL is faster).
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
to the user to get it for themselves?
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
./configure
make && make install
make && make rpm
rpm --install *.rpm
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Need EASY for END-USER install of source code
Nice paper.
Need EASY for END-USER install of source code
n most software, the "make install" command only uses a few simple
commands to actually install the software. In my experience, the most
common command by far is "install", which is hardly surprising. Other
common commands used in "make install" that might need redirecting from
privileged directories (like /bin, /usr, and /etc) include cp, mkdir, ln,
mv, touch, chmod, chown, ls, rm, and rmdir.
You forgot the horror which is libtool. That runs the compiler at
install time to do a link, so you have to wrap the linker! You may
get away without wrapping it if it turns out that it always asks the
compiler to put things in the srcdir, and then uses 'install' to move them
out.
Need EASY for END-USER install of source code
Need EASY for END-USER install of source code
But from what I've seen, someone who uses libtool will typically support
DESTDIR as well (I speculate that if you're a libtool user, you're
probably more interested in portability and thus more likely to support
DESTDIR).
True. A quick audit here shows few examples: APR/apr-util/apache are the
primary ones, but we know they're seriously weird to the point of not
supporting biarch building without ugly hacks (and they have INSTALL_ROOT
which you can use instead). (I mean, keeping around a copy of libtool from
your configure process and reusing it in other projects? Ew.)
Auto-DESTDIR released
Need EASY for END-USER install of source code
Ubuntu's multisearch surprise
> distributions.
> make && make rpm
> rpm --install *.rpm
> man-hours re-doing all the same work. [...] And, ironically, it's those
> binaries produced for Debian vs Ubuntu vs Fedora, etc etc... all are
> compatible with each other.
Ubuntu's multisearch surprise
OpenLDAP
People have, in the past, had huge issues learning LDAP with OpenLDAP. There is a wealth of documentation and examples on LDAP, but very little actually covers the initial setup and deployment of OpenLDAP. When you install OpenLDAP from Debian and Fedora it's built correctly, but it's a blank canvas...
The Debian packages these days actually provide a base entry and admin in the database, although this isn't well documented and requires a purge to do it again if you mess up. There are a few documents that properly cover setup, like Debian GNU: Setting up OpenLDAP although that assumes you'll use Kerberos instead of SSL to protect passwords, and my own LDAP for the Lazy Sysadmin which aims to be useful, if a bit ranty. But yes, most LDAP documentation assumes you already know LDAP and is more of a reference, or is just cargo-cult "do this to make it work" with no insight in to what's going on and how to fix it when it breaks.
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
by one version of a shared library end up being passed to another version
in the same address space, or if both of them are contending trying to
manage some shared resource (classic examples, both from libc: wtmp and
the malloc arena).
different shared libraries because they dared to use a symbol with the
same name' problem.
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
- audacious 1.x: blatant bug: the whole program is not servicing any X events when waiting to connect to a stream.
- audacious 2.1: the alsa output plugin hangs - playback just sits there at 00:00 - works with OSS. Does not play Internet streams at all. Dude, that's crap.
Ubuntu's multisearch surprise
** (audacious2:5101): WARNING **: could not open 'http://72.26.204.18:6314', no transport plugin available
Unable to read from http://72.26.204.18:6314, giving up.
ERROR: ALSA: alsa-core.c:226 (alsaplug_write_buffer): (write) snd_pcm_recover: Input/output error
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
> only support one distribution and none of them would agree on which
> distribution that was.
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
> introduced by distributors.
> upstream developer even takes notice of them.
* Do other distro packagers know about this problem?
* Will this one distro have the fix while other distros and the official source will be vulnerable?
* How does the distro packager know that their fix doesn't introduce another bug, security hole, or damage functionality?
> for the distribution I use unless all distributions are the same - in
> which case there wouldn't be any.
> for all, no package management that deserves the name.
> software themselves (which is a lot of work, btw!) would probably lead
> to something similar.
Ubuntu's multisearch surprise
> and was told it was okay. But they continued to make further changes to a
> similar piece of code that introduced a security issue.
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
I think the opposite
I think the opposite
the distro does a better job at packaging than the individual projects
ever could, besides, those don't have the resources to package for all
those distributions out there. I think the current scheme, while far from
perfect, is the best possible.
For newer packages on a released distribution, have you heard of backports?Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
> backports?
> python part of the OS? GTK+, Qt?
> several times.
Ubuntu's multisearch surprise
> middle of that spectrum, they have to choose
> between the two extremes. I administrate
> systems and compile software all day long
> at work. I don't want to have to do it when
> I come home as that's time I won't get to spend
> with my family. At the same time, I don't want
> to have the versions of applications dictated
> to me by my distro.
b) you don't want to to the things yourself becase you did them all day long at work
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
This seems to be a strong justification for the Firefox trademark policy which disallowed shipping non-default extensions. It seems like the bulk of the upset isn't that Ubuntu configured their default web browser to use their own search service -- it's that they configured Firefox to do it.
firefox trademark restrictions
firefox trademark restrictions
Mozilla is as bad or worse
Mozilla is as bad or worse
Mozilla is as bad or worse
Mozilla is as bad or worse
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
> sees the Google<->Mozilla Corp relationship for what it really is
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
address.
(The theory being most people won't change it to http://www.google.com/ if
they want Google set as their homepage.)
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
Privacy policies and Mozilla's compromised position
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise violates Google's Terms of Service too
Ubuntu's multisearch surprise
Careful
Ubuntu's multisearch surprise
Screw Firefox. It is becoming a monoculture and an attack vector.
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise