Weekly Edition
Return to the Announcements page
| |||||||||||||
The Ubuntu application review process
Canonical has announced a mechanism by which applications will be reviewed for possible acceptance into the Ubuntu Software Centre. "Recently we formed a community-driven Application Review Board that is committed to providing high quality reviews of applications submitted by application authors to ensure they are safe and work well. Importantly, only new applications that are not present in an existing official Ubuntu repository (such as main/universe) are eligible in this process (e.g a new version of an application in an existing official repository is not eligible). Also no other software can depend on the application being submitted (e.g. development libraries are not eligible), only executable applications (and content that is part of them) are eligible, and not stand-alone content, documentation or media, and applications must be Open Source and available under an OSI approved license."
(Log in to post comments)
Debian is no more upstream ? Posted Sep 22, 2010 8:03 UTC (Wed) by Alterego (subscriber, #55989) [Link]
If i understand correctly Debian is no more in the path for applications. I hope i misunderstood, because it would be much better for the ecosystem to keep things gathered instead of doing another reverse-upstream ((c) Canonical).
Debian is no more upstream ? Posted Sep 22, 2010 8:57 UTC (Wed) by mpt (guest, #53303) [Link]
You did misunderstand. Software packaged for Debian will continue to be synced to Ubuntu.
Debian is no more upstream ? Posted Sep 22, 2010 9:06 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]
Sure but why do we need two routes for applications to get into Ubuntu (via Debian as always and now via the Ubuntu Software Center)?
The article describes the how of the new process but not the why.
What problem is the Ubuntu Software Center solving that can't be done via Debian?
Martin
Debian is no more upstream ? Posted Sep 22, 2010 9:14 UTC (Wed) by ewan (subscriber, #5533) [Link]
It looks like it's intended for use by individual app developers to package their own app, then forget about it. Essentially it looks like the Apple App store process, but excluding proprietary software (for now?). Getting someone to the point where they can push a new package of their own software into Debian is a rather more long-winded process.
There is, of course, a good case to be made that that is a good thing.
Debian is no more upstream ? Posted Sep 22, 2010 18:15 UTC (Wed) by jsanders (subscriber, #69784) [Link]
Absolutely. I've reached the point where I'm giving up trying to get the Debian package of my software in the repositories. You just get a wall of silence from the mailing lists if you try to get a mentor. Becoming a Fedora package maintainer was simple for me. This might indicate how Debian's processes have become bogged down.
Debian is no more upstream ? Posted Sep 23, 2010 0:20 UTC (Thu) by drag (subscriber, #31333) [Link]
The way it should work is that all packaging is done by upstream developers with the assistance of the distributions. This is opposite of what happens now (especially with Debian) with most packaging done by distributions with the assistance of the developers.
Dealing with installation issues and compatibility should be handled as part of the source code distribution like documentation or anything else and should be part of the programmer's repository and responsibility. They are the ones that know the software the best.
It's not scalable nor efficient use of resources to have each distribution do all the work of packaging software individually in it's own little cloud. It really does not make sense at all.
There are certainly parts of the system that need to be handled by the distributions... but as far as real applications that are meant to be used by end users and other software does not have large dependencies on it then it should be 100% pre-packaged downloads for distributions and end users.
The distributions should cull the 'best of breed' of applications and provide them by default to end users.
If Ubuntu's application store is only asking developers to make their own packages and make it easy for end users to get access to those packages then that is a significant improvement over what Debian does with ftpmasters and whatnot.
It's like the difference between cvs or git. Linux stuff works best when it's a distributed effort. Anybody should be able to make packages and anybody should have relative easy access to those packages with only the mimimally _needed_ vetting and quality control. If there are bugs or conflicts or broken packages then just work with the developer to get that stuff fixed.
There is no really useful reason to get all nazi about what you allow in and whose packages you allow easy access to by the end user.
Debian is no more upstream ? Posted Sep 23, 2010 0:27 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the problem with saying that the developer should be responsible for all upgrade issues is that the distributions usually decide that they know better than the developer where the program files should be. As such, making the developer responsible for knowing how every distro has decided to do things is unreasonable.
Another issue is dependancies. Different distros have different granualarity when packaging libraries and other things that a application may be dependant on. One distro may only require a couple specific packages for the application to run, but on another the same software could require many more packages (especially since different distros have different things installed by default). Figuring out what the proper dependancies are for a package should be the responsibility of the distro maintainers, not the application developers.
Debian is no more upstream ? Posted Sep 23, 2010 1:13 UTC (Thu) by drag (subscriber, #31333) [Link]
> the problem with saying that the developer should be responsible for all upgrade issues is that the distributions usually decide that they know better than the developer where the program files should be. As such, making the developer responsible for knowing how every distro has decided to do things is unreasonable.
True; making a developer know and understand all different aspects of different distributions is unreasonable.
However it is a technical problem that can be addressed and fixed by distributions, however, in a fairly obvious and straightforward manner.
> Another issue is dependancies. Different distros have different granualarity when packaging libraries and other things that a application may be dependant on.
This is fixable, too.
This issue and the one above should be considered serious bugs that Linux OSes in general need to address.
> One distro may only require a couple specific packages for the application to run, but on another the same software could require many more packages (especially since different distros have different things installed by default). Figuring out what the proper dependancies are for a package should be the responsibility of the distro maintainers, not the application developers.
Yet, ironically, the libraries and versions that are needed to run a program successfully is far better well known by a upstream programmer then a distribution.
These are all severe technical issues with Linux have have never been addressed, not because they are not obvious problems, but simply people have refused to deal with them. Instead decided to address the issues by papering over issues with package management combined with a huge amount of mostly redundant manual labor.
It does not scale. It is extremely inefficient.
The core of the problem here is the refusal of distributions to work together.
This has created a situation that while Linux distributions are technically open they are in fact much more closed ecosystems and much more hostile environment to independent developers and end users then iPhone, Android, or Microsoft Windows ever was.
Debian is no more upstream ? Posted Sep 23, 2010 6:24 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the reason that the distros don't all split things the same way is that there are different ways that they can be split, and each of the different ways has advantages and disadvantages.
add to this the fact that different distros have different criteria for what 'tested enough' means and you have the same total set of libraries not only split up in different ways, but you also have the possibility of different versions of the libraries.
since there is no single criteria of what is best you are never going to get everyone to agree on the 'right' way to do things.
yes, this is a weakness of linux, but it's also one if it's great strengths. The possibility of a new distro starting up and becoming wildly popular (Ubuntu being a recent example) prevents things from stagnating.
the fact that Linux has been able to have this diversity while still remaining basically compatible (even if not as binary friendly as some would like) is a major accomplishment.
Debian is no more upstream ? Posted Sep 23, 2010 9:07 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> the problem with saying that the developer should be responsible for all upgrade issues is that the distributions usually decide that they know better than the developer where the program files should be. As such, making the developer responsible for knowing how every distro has decided to do things is unreasonable.
This would be solvable by having the upstream developer do the packaging in a meta-packaging format which could be automatically converted to the actual RPM/deb/whatever. The meta-format could contain information about which files belong to which categories (documentation, binary, library, whatever) and the conversion tool could build the software with the right paths hard coded (or better, the upstream author could get rid of hard-coded paths in the software) and then put the files in the right places. You wouldn't even need to standardise on a meta-format as long as you chose one which most distributions could support.
> Another issue is dependancies. Different distros have different granualarity when packaging libraries and other things that a application may be dependant on. One distro may only require a couple specific packages for the application to run, but on another the same software could require many more packages (especially since different distros have different things installed by default). Figuring out what the proper dependancies are for a package should be the responsibility of the distro maintainers, not the application developers.
Again, the dependencies can be expressed in a distribution-independent way by refering to the name of the upstream source archive, possibly qualified with the name of a library or a binary for archives likely to map to several distribution packages. This could be translated automatically to what the distributions need.
Debian is no more upstream ? Posted Sep 23, 2010 13:37 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> As such, making the developer responsible for knowing how every distro has decided to do things is unreasonable.
Actually there is another alternative to using a packaging meta-format, and one that is simpler for applications that are going to get packaged by a distribution anyway - the packaging is still done by distribution people, but they work directly upstream, which makes the "primary" upstream developers much more likely to look at what they are doing, and makes it easier to say share rpm packaging between SUSE, Redhat, Mandriva and whoever, and deb packaging between Debian, Ubuntu and whoever else. From experience sharing packaging between distributions in this way doesn't have to make it uglier than unshared packaging (the extra discipline it enforces may even improve the quality).
Debian is no more upstream ? Posted Sep 23, 2010 17:15 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I agree that more of the packaging work should be upstream.
for example, rsyslog used to have a build option to create .deb packages. It was removed at the request of the debian maintainer because he had conflicts between what was upstream and what he did in preparing it for debian stable.
this made that maintainers job easier, but it made it harder for people who want a newer version than what debian ships
Debian is no more upstream ? Posted Sep 23, 2010 19:56 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> for example, rsyslog used to have a build option to create .deb packages. It was removed at the request of the debian maintainer because he had conflicts between what was upstream and what he did in preparing it for debian stable.
I suppose that in my version of the story he would submit patches to upstream to adjust their .deb building infrastructure to match what he needed.
Does it make any sense without being a Debian developer to talk to the Debian people about this sort of thing?
Debian is no more upstream ? Posted Sep 23, 2010 22:21 UTC (Thu) by foom (subscriber, #14868) [Link]
> for example, rsyslog used to have a build option to create .deb packages. It was removed at the request of the debian maintainer because he had conflicts between what was upstream and what he did in preparing it for debian stable.
Yes, that sort of thing was unfortunately common.
For a long time, there were tool issues that made it difficult to make a debian package for debian, when the upstream tarball also had a debian/ directory at the toplevel. Thankfully, that issue has now been resolved with the dpkg source format version 3, so there's no longer any reason for such requests.
Debian is no more upstream ? Posted Sep 23, 2010 22:27 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
if it's no longer necessary to not have this in the upstream package, is it reasonable to ask the debian developers to attempt to submit the needed changes back upstream?
Debian is no more upstream ? Posted Sep 23, 2010 20:04 UTC (Thu) by alecs1 (guest, #46699) [Link]
I'm very happy this particular point of distributing packages is coming up increasingly often, because solving (at least partly) the problem makes Linux more prepared for a little wider adoption.
If I remember correctly, drag has been arguing about this before, and now I can only support his view after I found out very surprised that installing any KDE 4.X version (or combination of versions) was a few clicks away on Windows, but a really serious job on Debian (to give just an example).
I guess there's no need to argue that software availability is a major point in having average users use Linux.
Debian is no more upstream ? Posted Sep 22, 2010 10:11 UTC (Wed) by gowen (guest, #23914) [Link]
Debian's definition of Free is not the same as Ubuntu's -- Ubuntu free is a superset of Debian free. That's not a problem, necessarily, but it may make a difference for some people. Secondly, Debian has well understood rules and processes about becoming a Maintainer or a Developer. Again, a (fairly sizeable) difference, given the fairly involved process to become a Debian Developer.
Debian is no more upstream ? Posted Sep 22, 2010 15:25 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]
Yes I agree the process for becoming a DD or DM is fairly involved.
However in most cases the packager is not the upstream author. That means you shouldn't need to become a DD or DM to get your application into Debian / Ubuntu. If your application is open and considered useful fairly widely it will probably be packaged by a friendly DD or DM. Given the large number of (sometimes fairly esoteric) packages in Debian today this seems to work fairly well already.
I'm worried that this is about setting up the infrastructure today that could be used for a closed "Ubuntu App Store" tomorrow. There would be a motivation for this since DD's and DM's aren't going to be able or willing to package non free stuff.
Debian is no more upstream ? Posted Sep 22, 2010 16:57 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
as a package developer, you only don't have to be the debian maintainer if someone else steps up and volunteers to do the job for you.
not all packages have a maintainer willing to do the work.
one example would be twiki, which is fairly popular, but was removed from debian because it was considered to difficult to maintain.
Debian is no more upstream ? Posted Sep 22, 2010 17:44 UTC (Wed) by vonbrand (subscriber, #4458) [Link] If twiki (for instance) is deemed too hard to maintain for Debian, and nobody there steps up to the job, what makes you think somebody will do it for Ubuntu?
Debian is no more upstream ? Posted Sep 22, 2010 17:52 UTC (Wed) by gowen (guest, #23914) [Link]
I suspect that Ubuntu will have a more carefree attitude toward it being unmaintained. Once approved, a developer may well be free to ignore it, even if there's a security bug, the ubuntu core team will think of it as essentially third party software that they happen to ship from their servers. It certainly matches the criteria for inclusion: one version approved; no dependencies relying on the developer to fix bugs. With their six-month upgrade cycle, you minimise the period for there to be any appreciable bit-rot on.
That's not based on any evidence though, its just a guess.
Debian is no more upstream ? Posted Sep 22, 2010 20:55 UTC (Wed) by vonbrand (subscriber, #4458) [Link] That would be a disservice to their users (and open source in general): Just package up any random junk, if it doesn't blow up today under cursory testing, ship it. Then let it rot, or get random "updates" that aren't checked at all (let alone closely). Thanks, but no thanks. I use a distribution exactly because I don't have the expertise (nor the time) the check and keep a staggering set of packages up to snuff, and I rely on my distribution to do (most of) the heavy lifting here.
Debian is no more upstream ? Posted Sep 24, 2010 15:00 UTC (Fri) by cortana (subscriber, #24596) [Link]
You have pretty much described the Ubuntu packaging and maintenance process. :)
Debian is no more upstream ? Posted Sep 23, 2010 17:22 UTC (Thu) by ewan (subscriber, #5533) [Link] Based on a comment to the original article it would appear that they're aiming explicitly for 'no updates', so there won't be any worries about maintenance because there isn't going to be any.
Debian is no more upstream ? Posted Sep 22, 2010 17:53 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
because the criteria may be different?
Debian requires that the same version be supported for the life of the stable distro, this may not have the same requirements and may allow the developer to change to a newer version a year or two from now.
Debian is no more upstream ? Posted Sep 22, 2010 17:56 UTC (Wed) by donbarry (guest, #10485) [Link]
The case of TWiki is actually more complicated. The project was seized by the
trademark holder who locked out the developers from the project servers unless they would accept an agreement naming the trademark holder the "benevolent dictator for life." Essentially every core developer left, forking the codebase to the Foswiki project. The Debian packager, Sven Dowideit, indicated he could no longer maintain the twiki package for a variety of reasons, including of course his inability and unwillingness to participate meaningfully within the twiki effort under those constraints, since he could not easily push security patches upstream.
He did quickly create Foswiki packages, though pushing these packages to Debian
Momentum for the two projects: http://bit.ly/fwstats
Object lesson: be careful about pissing off your developers. You may end up with none.
Debian is no more upstream ? Posted Sep 22, 2010 20:25 UTC (Wed) by mpt (guest, #53303) [Link]
Debian is an operating system. Ubuntu Software Center is a package management utility.
If you mean, What problem is the Application Review Process intended to solve that cant be done via Debian?, there are two main answers.
The first is scale. Ubuntu has roughly 3500 applications (out of 30-odd thousand packages). Were competing with operating systems that have on the order of a hundred times as many applications. Debian Developers, and our own Masters of the Universe, do fantastic work and they will continue to do so. But its utterly implausible to suggest that their ranks will ever multiply a hundredfold to handle that kind of workload. Now, maybe there is more automation we could do. Almost certainly, the packaging system could be simpler. But the single biggest way for us to scale is for more upstream developers to take on responsibility for packaging their own new applications, like they do for popular operating systems.
The second answer is speed. If you submit a new iPad application, for example, there is (as of earlier this month) an 83% chance it will get into the App Store within a week. If you submit an Ubuntu package for our official repositories, on the other hand, the equivalent process takes between 2.5 and 8 months, depending on which point of the release cycle were at. And even then, a user needs to upgrade their entire operating system before your application will even show up. This is absurd. Now in theory, you could become a DD or MOTU, get your application into the development release, and then propose a backport to the stable Ubuntu release but thats such a byzantine and non-obvious process, hardly anyone bothers. Developers need to be able to make their software available, quickly, in Ubuntu Software Center, on the versions of Ubuntu that people are already using. This Application Review Process is a small step towards that.
Debian is no more upstream ? Posted Sep 22, 2010 10:50 UTC (Wed) by duelafn (subscriber, #52974) [Link]
From the blog comments: "The idea of the ARB is to push apps post release. If you want something in before release you should go to main or universe."
Debian is no more upstream ? Posted Sep 22, 2010 12:39 UTC (Wed) by NAR (subscriber, #1313) [Link]
There are at least three ways for an operating system to manage application installation:
- there is the DOS/Windows-way: acquire the software somehow (buy on floppy/CD, download from the Internet, etc.), then install it. You can install virtually any combination of software, they don't depend on each other much, because they don't share many libraries, everybody bundles the necessary dll files. - there is the Linux distribution way: you get all software from a central repository, which are "guaranteed" to work with each other, they share lots of libraries and also the distributor might check if the software is not malware. - there is the iPhone-way: you get all software from a central repository, but they are developed independently, they don't depend much on each other.
The Windows way was quite successful. Although it is not considered secure, because the bundled dlls are not upgraded when there's a security flaw - does it really matter?
Debian is no more upstream ? Posted Sep 22, 2010 13:07 UTC (Wed) by RCL (guest, #63264) [Link]
The whole FOSS idea is based on the assumption that users are to some extent developers of the software they use (even if it means that they only test it). This sets the natural boundaries for how much Linux/other FOSS OSes can spread.
Canonical is trying to overcome that and provide the system for users who are indifferent or even hostile(*) to the environment they use. Let's see...
(*) as is: easily irritated by its imperfections.
Debian is no more upstream ? Posted Sep 22, 2010 14:52 UTC (Wed) by mpr22 (subscriber, #60784) [Link] The Windows way was quite successful. Although it is not considered secure, because the bundled dlls are not upgraded when there's a security flaw - does it really matter? Yes, it absolutely does matter. The Windows way built up its success in an era when many people didn't have Internet access, and many of those who did were stuck on dialup. It didn't matter so much that those Windows systems were insecure, because the only people likely to be seriously affected by those computers being compromised were the people who owned and used them (and besides, it was probably more cost-effective for someone wanting to do serious wrong to dig up the latest remote root exploit in bind or sendmail). Now... Joe User has always-on ADSL and may even be leaving his computer running overnight (e.g. to grab something over a torrent). That turns his security problems into our service-level problems.
Debian is no more upstream ? Posted Sep 22, 2010 15:27 UTC (Wed) by NAR (subscriber, #1313) [Link]
I meant - do I care if e.g. the zip library used by the GTA game has security holes? No, I don't care, because it only opens the files delivered with the game (I have no idea if the game has anything to do with zip files, it's just an example). I think there are plenty of such libraries where a possible security hole is just not important.
But in the Linux-way when every application should use the same shared library, the zip library will be updated and if the game depended on a particular feature/bug in the old library that was broken/fixed, the game itself won't work. And we all know that applications tend to workaround bugs in libraries and these workarounds tend to break when the bug is fixed. This is the stability that the Windows-way (and possibly the iPhone-way) gives to users, but the Linux-way fails to provide.
Debian is no more upstream ? Posted Sep 22, 2010 15:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
"I meant - do I care if e.g. the zip library used by the GTA game has security holes? No, I don't care, because it only opens the files delivered with the game"
Unless the game automatically downloads custom maps (built by other players) when you want to play a multi-user game.
Debian is no more upstream ? Posted Sep 22, 2010 18:00 UTC (Wed) by nicooo (guest, #69134) [Link]
> I think there are plenty of such libraries where a possible security hole is just not important.
zlib is the worst example you could give, since it's used by hundreds of programs. The security hole from a few years back is probably one of the main reasons why distributions are against bundled libraries.
Debian is no more upstream ? Posted Sep 22, 2010 19:56 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
> zlib is the worst example you could give, since it's used by hundreds of programs. The security hole from a few years back is probably one of the main reasons why distributions are against bundled libraries.
I'm sure that this must be fixable in a more distribution or AppStore-like model as opposed to a Windows-like grab and install model. For instance, packages which bundle libraries but don't need modified versions of them could be build in a standard way, so that you can tell automatically which package bundles which version of which library. While I have my doubts as to whether committing to specific versions makes sense for FLOSS stuff (being more flexible gives you more solid testing, and there will normally be enough people among your users who can fix the extra issues), bundling as such would still bring a number of advantages.
Can anyone venture an idea of what the actual costs are likely to be in terms of wasted disk and memory space, given that these days data and not code is often the heavy part?
Debian is no more upstream ? Posted Sep 22, 2010 20:23 UTC (Wed) by dbruce (subscriber, #57948) [Link]
"And we all know that applications tend to workaround bugs in libraries and these workarounds tend to break when the bug is fixed. This is the stability that the Windows-way (and possibly the iPhone-way) gives to users, but the Linux-way fails to provide."
Speaking from personal experience, usually the "workarounds" consist of writing some other valid code that doesn't trigger the bug, rather than writing something that relies on the bug's existence. If a program breaks when a library bug is fixed, the program itself has a bug.
Anyway, if for any reason a linux app doesn't work with more recent versions of a library, generally a new version of the app gets released. So the "Windows-way" just allows old versions of libs to be kept so that old versions of apps keep running, bugs and all. The user may be bothered less, but it is worse from any reasonable engineering perspective.
The "Windows way" is why the work-owned PC I am posting from still has IE6. We have custom-written programs that rely on the non-standard behavior of IE6.
Debian is no more upstream ? Posted Sep 23, 2010 1:39 UTC (Thu) by drag (subscriber, #31333) [Link]
At my work we have to deal with lots of software that is still running Redhat 3.x ES and Solaris 9.
Is this because we do it the 'Windows way'?
Fuck no, that is retarded. It's because software programming is a huge pain in the ass that is expensive and difficult to get working in the first place and once we get it working we do not want to continually f*k around with it because there is a crapload of other things there are much more important to do. Then periodically we put a lot of effort into upgrading the OS.
Think about it:
Why the hell do people use 'Debian Stable' for servers?
It's because on production servers almost nobody depends 100% on the packaged software, OF COURSE. They have a crapload of custom scripts, third party software, edited HTML, custom java script, custom database tables with custom applications, custom backends, custom front ends, and all that crap they have to deal with.
When YOU run a server do you always use 100% pre-packaged software? If you do it's only because your using your servers in trivial situations were most of the interesting problems have been solved over a decade ago.
This is why Linux is often the best distribution for these server situations because it makes the life of the hacker and business developer easy compared to using other server operating systems. That is Linux distributions cater to the needs of server users that build complex applications and dependencies based on 'AJAX' or 'LAMP' or whatever.
They do not expect that when you build a website that you should be forced to submit your source code to them for approval and packaging before your end users are allowed to use it without pulling their hair out.
But Oh... No.... When it comes to the desktop we should only expect that people will only want to run pre-packaged software. That the software provided with a particular version of Debian's repositories is the only thing that any and all organizations should ever want or ever need. That Debian apt-get can package all the software that users will want to use and that if it's not packaged then it's not good enough anyways. No desktop user depends on custom scripts and no organization needs to have custom applications that they need to maintain themselves. All that is impossible and is the useless 'windows way'.
--------------------------
In your statement replace 'The Windows way' with 'How shit works in the real world' and then THAT would be a accurate statement.
If your business depends a lot of custom internal applications that depend on Firefox 2.x implementation of "XUL" you'd better believe it that you would be forced to deal with installing Firefox 2.x on all your desktop machines no matter how inconvenient or ugly it is and no matter how much a Linux distribution makes that a huge PITA.
Debian is no more upstream ? Posted Sep 22, 2010 16:17 UTC (Wed) by rvfh (subscriber, #31018) [Link]
> there is the DOS/Windows-way: <snip> everybody bundles the necessary dll files.
Note that there are some limitations to that, like games bundling and installing the latest Directx update, or the installer telling you that it's going to replace an existing DLL in system32 by an older one.
Debian is no more upstream ? Posted Sep 23, 2010 8:01 UTC (Thu) by cmccabe (guest, #60281) [Link]
> The Windows way was quite successful. Although it is not considered
> secure, because the bundled dlls are not upgraded when there's a > security flaw - does it really matter?
Seriously-- is this a joke? Of course it matters if software is insecure. Just ask Microsoft. They've spent a lot of effort improving their security recently (with some success.)
Bundled DLLs have some other problems you didn't mention. They can't be shared between different applications, increasing memory consumption and load time. Since each application is using a different version, the latest and greatest version gets less testing, so bugs can persist for longer. People tend to fork the library into their own weird dead end branch.
At the end of the day, Windows is a different environment than Linux. In Windows, software is developed mostly by commercial entities who have little interest in working together or helping one another. There just isn't a lot of code sharing that goes on. The concept of a suite of tools that work together is kind of foreign to Windows. You tend to see some giant app that tries to assimilate everything inside itself. Conflicting similar apps often step on each others' toes. Since there's no central authority vetting software, malware is commonplace. Corporate IT departments usually deal with this by imposing draconian restrictions on what software you can install on your workstation.
Linux desktop software is developed mostly by hobbyists. There is less manpower available to improve things, so code sharing is very important. It's considered acceptable, maybe even laudable, to write an app that just does one thing well, rather than trying to lock your users into some giant "software suite."
In general, one technology never displaces another just by being a slightly better version of the same thing. Betamax couldn't eclipse VHS just by offering slightly better video quality. DVDs, on the other hand, offered crisp digital video, easier storage, and some other advantages that eventually allowed them to completely displace VHS. The people who are trying to build a "better Windows than Windows" need to rethink their strategy. You don't win with incremental improvements. You win by offering something radically different and better.
> My main problem is the interdependency - a new version comes
You know, that's why they invented LD_LIBRARY_PATH. Static linking would also work.
Debian is no more upstream ? Posted Sep 23, 2010 12:45 UTC (Thu) by mpr22 (subscriber, #60784) [Link] Couple of problems with your last sentence: If your program needs to be setuid/setgid for some reason, you can't use LD_LIBRARY_PATH, and ISTR at least one interpretation of the LGPL says that if you statically link against LGPL'd libraries you have to licence your program in an LGPL-compatible way. Someone who wants to only distribute binaries almost certainly doesn't want to do that... so they'll add their software to the Windows software ecosystem instead. (I also STR that some libraries are designed on the assumption that they won't be statically linked ever, but I'm even less confident of that memory.)
Debian is no more upstream ? Posted Sep 24, 2010 7:06 UTC (Fri) by cmccabe (guest, #60281) [Link]
> If your program needs to be setuid/setgid for some reason, you can't use
> LD_LIBRARY_PATH, and ISTR at least one interpretation of the LGPL says > that if you statically link against LGPL'd libraries you have to licence > your program in an LGPL-compatible way. Someone who wants to only > distribute binaries almost certainly doesn't want to do that... so they'll > add their software to the Windows software ecosystem instead
The best solution is to factor out the parts that need to be setuid into a small standalone binary. Then you can just exec() that when you need to, or use IPC to tell it what to do. Basically implementing privilege separation, which you should do anyway for security reasons, solves this problem.
If you don't care enough to use privilege separation, you could set up a chroot environment with exactly the libraries that you want.
In my experience, most companies that release binary blobs for Linux also release such blobs for Windows and other operating systems. For example, Matlab is available for Windows and Linux (and maybe some other operating systems.) So they don't tend to rely too much on operating system specific functionality. So I don't see why they would really care if they were using glibc or the BSD libc. Also, newlib is another libc which seems to be under BSD-ish licensing.
Debian is no more upstream ? Posted Sep 23, 2010 14:46 UTC (Thu) by andrel (subscriber, #5166) [Link]
Is Linux desktop software really mostly developed by hobbyists? Development of the most important apps (including Firefox, Thunderbird, Openoffice.Org) is driven by full-time staff.
Debian is no more upstream ? Posted Sep 23, 2010 15:06 UTC (Thu) by TRS-80 (subscriber, #1804) [Link] Ubuntu has always had multiple upstreams; particularly GNOME has always been packaged directly instead of going via Debian.
The Ubuntu application review process Posted Sep 25, 2010 1:00 UTC (Sat) by forlwn (guest, #63934) [Link]
If this is the first step for the Ubuntu's most needed part company from Debian dependency, Id take off my hat and say: Kudos to Canonical. And no, I'm not afraid this means Canonical's Ubuntu is going to be closed or paid, in the future.
|
|||||||||||||