What possible benefit does migrating from one expensive proprietary OS to another just like it have?
No, security isn't an argument, Microsoft is not only catching up fast there but Apple have fucked up time and time again with that (remote code execution via Safari only a couple of days after releasing Tiger? WTF?).
Usability isn't really an argument either. MacOS interface is sufficiently different from Windows - usually for no better reason than "that's how Mac always did it" - that retraining costs would be higher than for Linux.
Not being Microsoft definitely isn't an argument. Apple have an equally crappy reputation for control freakery and general arrogance.
Virtualisation isn't a long term compatibility solution either. You need something like Wine for that - otherwise you will always still have Windows licenses and systems to maintain even if they *are* virtualised. Not to mention the huge RAM overhead it entails.
Put bluntly, there are no reasons for business to migrate to the Mac, and many reasons to avoid it. That's why Apple chase the home/consumer market so aggressively.
Yeah, I read it. All except the last paragraph - whoops:)
I totally agree with the general thrust of your post though, now is the time. But who will run the last mile? Who will step up? I don't know... we need superheros and they're badly lacking right now.
Yes, it's not "fixed", not by any stretch of the imagination. It'll hopefully be fixed several years from now when Linux developers know of autopackage as well as they know of RPM today, and there is a culture of developers being expected to provide them just as they are expected to provide a GNU autotooled source tarball today.
Anybody can help with this process, by pushing autopackage towards critical mass. That means asking developers of your favourite projects to provide them.
Incidentally, if Asa is reading this, there has been a Firefox autopackage for ages but the Mozilla developers refuse to accept it upstream!
Autopackage supports bundling of single libraries, entire packages and even if the dependency is not bundled you can put the package in the same directory as the one you are installing and it will look there.
We also provide tools that make Apple-style "weak linking" very easy (that is what relaytool does) and also a dep solver.
In other words, we provide every means of handling dependencies: the Linux way (depsolve), the Windows way (bundle), the Apple way (weak link). Exactly which a package uses is up to the authors: we're still trying to figure out some guidelines on what is best to use.
That's correct, Ubuntu Universe is disabled by default, despite the fact that most of the packages you will want are there.
This is silly. It's been raised on the Ubuntu lists time and time again. Nonetheless, they refuse to enable it, because Canonical can't guarantee security updates for it. That's also silly, in my books, but then I find the whole idea of a Universe repository very silly indeed; it's simply not possible for a distro to ever be 'finished' like that.
Unfortunately, whilst new means of distributing software are being developed, the distribution developers generally strongly dislike them and sometimes go out of their way to cause difficulty for them. At some point there'll probably be a new wave of distros derived from the current ones that take the last "easy steps" to make Linux really usable for family and friends. Hell I'll do it myself one day if need be. Fedora is so close yet so far!
Still... it's easy for Asa to criticise now. But think about all those years that Mozilla lumbered on with essentially zero popularity outside of the geek world. It wasn't until Firefox (which took years to develop) reached version 1 that things really took off. Linux is still in the Mozilla Seamonkey stage: cute features are being developed but that last stretch hasn't been reached yet. Arguably, it hasn't even been started.
$100? That's only about 50 quid: I think you mean more like $220.
Still, that said, I have been a license fee payer in the past (not now though), and it was worth every penny if only because adverts interrupting dramatic programs totally sucks!
You're assuming every program dynamically links to libZ. That isn't the case at all: statically linked or private copies of this library are common.
What's more, Windows not having a package manager doesn't mean they're necessarily worse off. Think about it - if the zlib code was in Windows, they could just update the affected DLLs using Windows Update. If it isn't in Windows, then by definition it wouldn't have been packaged anyway.
The scanners can also detect knives and guns, not just explosives.... generally anything hidden under the clothes. It's also possible to hide explosives from animals if you know they may be present in advance.
Of course, the fact that these days QinetiQ are a commercial R&D company who work on everything from train timetables to mobile phone contracts is a minor insignificant point. They're a part of the military industrial complex dontcha know.
At this point, I'll say that I work for them as a summer student. QinetiQ are the organisation formerly known as DERA, or the Defence Evaluation and Research Agency. As defence spending has been dropping year on year for a long time now, it was felt it'd be better to privatise the organisation rather than simply let it fade away.
These days, while a large amount of their work still comes from MoD contracts, they're diversifying at a fast rate.
As to whether there's some secret keiretsu involving QinetiQ, Caryle and the Bin Laden family (who IIRC disowned Osama many years ago), well that's a matter for conspiracy theorists and documentary writers. I see a simpler explanation: Carlyle have a history of investing in defence contractors so they know the territory, and they're one of the biggest private equity groups because they have a lot of investments. At some point there will always be overlap, and what you see there says more about yourself than anything else.
Yes, exactly. Berlin or whatever it became known as was quite innovative, but had some dubious design choices such as the use of CORBA for widget tree remoting that did it in.
Typically open source projects are quite conventional because the people working on them aren't out to take over the world, they want to produce something useful that they know will solve their problems. For companies, they can say "we'll have 20 people work on this for a year" and if the end result sucks and nobody uses it, it just gets thrown in the trash can and never sees the light of day.
When individuals work on open source development the motivations are different. When companies work on open source development, they typically have some near term problem they want solving and "innovation" would get in the way of that because you're just as likely (assuming it's truly new) to end up with a turkey as a golden goose.
All of this is generalisation of course. You can get innovation in Linux, and I'd expect to see more and more of it as core infrastructure issues get solved increasingly rapidly and more developers move out into app development.
Re:These "innovations" are up to 40 years old.
on
Ballmer on Innovation
·
· Score: 1
Oh for goodness sake, readline is not and never has been an equivalent to IntelliSense. Ever.
The guys original posting was right on the money: people often abuse the word "innovation" especially when talking about technology companies. Microsoft have certain done things very well and popularised them, and yes certainly some wacko obscure package or OS had them first. Great. The same is true of pretty much everything Apple has done too - so why are Microsoft not "innovative" but Apple are? This was the OPs point, and you demonstrated it neatly by using Smalltalk and Manx C as counter examples.
What makes you think those guys understand security?
I've seen more than one distro provided security fix be put out for non-existant security issues, that were very obviously non-existant (eg, discussed on the mailing lists and proven to be non-exploitable).
Debian isn't the only group that fixed a non-existant bug (for Wine). Gentoo did it too, for Mozilla. There are probably more examples: these are ones I came across randomly without looking for them.
Ubuntu has a lot of hype. It's a nice distro but remember Fedora!
Sound - fixed in FC4. ALSA dmix takes care of this for sound cards that can't do hardware mixing. It works for every ALSA app, which most programs now support. The "aoss" program can be used for apps which still use OSS (though it should be applied automatically... expecting users to know this is silly)
Synaptic was never designed to have a good UI, it was designed as a frontend to apt-get. Try autopackage if you want software installs with a simple and straightforward user interface. Yes, not many packages yet. That is teh suck. Ask your favourite projects maintainers to build them!
Applications - you should never have to add items to the menus manually. If you need to do that, it's a bug in the application itself (some apps just don't register menu entries). Why not send a polite email to the maintainer asking them to add a menu entry and icon for their program?
One other person said they had to wait several hours for it to show up, or that they had to restart gnome-panel to make them appear. This is always a bug; the items should appear instantly. Unfortunately the "gamin" server which is replacing FAM has had a lot of teething problems, in my experience. Make sure your system is fully up to date. It's a pretty good demonstration of Spolskis "don't rewrite software" maxim.
Firefox - not much to say here. Yes, it can be slow with lots of tabs. There are a bunch of nasty memory leaks fixed in the "Deerpark" release that should be going stable soon.
Folder Navigation - this is only a problem in Ubuntu, which unilaterally decided to change the file manager so the old window closed itself when a new window was opened. In the "real" version which Fedora uses, they stay open. The downside? If you have deeply nested folders, you get lots of windows. The upside? Easy to have multiple folders open at once. For the next GNOME version the Nautilus browser view is getting much improved: it's likely that Ubuntu will switch to browser mode by default at that time rather than continue to hack spatial mode.
The launcher application is the.package file itself: instructions to install an autopackage file are to set it executable and then run it. That process includes no sanity checks whatsoever.
No, that's only the first time, before you have autopackage on your system. After that they're associated with a launcher app in the GUI so when you click it, the file is passed to an intermediary.
If you want to run it from the command line, then it's currently assumed you know what you're doing, but it'd not be hard to switch to an intermediary like with the GUI there too.
As for --noscripts, well, that's great... who uses that option in day to day life? Nobody, because some packages do depend on scriptlets and will break in mysterious ways if they aren't run.
Autopackages will back up any file they overwrite rather than just erasing it, like RPM would (the conflict detection only works if everything is installed via RPM, which often isn't the case).
Obviously the package scripts would not be in charge of verifying their own authenticity, that'd be a dumb design. The launcher application which is associated with.package files would do that, and only pass control to the package itself once verified. That's no different to RPMs which can contain arbitrary scriptlets.
RPM provides no security. They must always be run as root, and can run any program or software they like, at root privileges. There is no functional difference between an RPM and an executable binary: they can both do whatever they like
Autopackage has at least four different mechanisms for dealing with dependencies, including static linking, bundle linking, weak linking and a dependency resolver, why don't you read up on it instead of bashing it? All of your issues are covered in the FAQ.
Autopackages aren't really ad-hoc installers, they're actually a hybrid of RPM style packages and wizard-style installers, combining the best elements of both. They understand dependencies, are low overhead, are built from specfiles and have a consistent and integrated user interface. Nonetheless, (when done well) they are easy to use and look professional. I fail to see how this is a step backwards given the reality that not everybody uses the same distribution.
The button order uses the GNOME HIG unless you're running inside KDE, at which point they swap over to be consistent with the rest of the desktop. Unfortunately the screenshots were taken using KDE, I need to get Taj to regenerate those using GNOME.
First is user acceptance. There are those that prefer a central repository for all their software needs, rather than going through the 'hassle' of navigating to the developers website,
Yes, absolutely. Actually this camp of people tends to split into two quite different types:
Those who like the "name that package" style of user interface. I'd be the first to admit that I like this UI too, it's very convenient and powerful when you know the name of what it is you want (of course, if you don't, then Google smacks apt-cache search around any day).
Those that actually believe in fully centralsied repositories
Obviously autopackage will never please the latter type, but this is in my experience a vocal minority. Usually when people say they like apt, what they mean is they like the convenience of the command line for when they know what they want.
There's no reason you could not implement this UI on top of autopackage using a DNS style naming/lookup service. It would not be hard to do, and if anybody is reading this message and wants to help implement it let us know. We already have basic blueprints for such a feature.
Second is developer acceptance and support. This is the same as you said, but with an added clause. When developers use autopackage, they need to advertise it as the optimal choice for users browsing their website.
Totally. We have a PHP developer who has written some code that auto-selects which packages to show the user based on their User Agent string. I still need to drag it out of him and get it documented, advertised on the website etc. I keep meaning to write an article or somesuch on website design for open source projects; far too many people link directly to their SourceForge download pages which is awful UI.
Third is vendor acceptance.
So there are two types of vendors here: software developers, both open source and commercial, and distribution vendors.
I think it's fair to say that distros like Fedora and Ubuntu will give up yum and apt over their dead bodies. They're unfortunately sold on the idea of centralised packaging.
On the other hand, the "first time setup" procedure isn't all that hard, unfortunately the UNIX non-security system of +x bits gets in the way but after you run your first autopackage succesfully that's no longer an issue. Autopackage is taking off amongst the indie software developer community, especially the open source gaming community. Again we simply need more people - developers are wanted, but any enthusiastic Linux users who want to help spread the word are also quite appreciated and we can put them to work.
For projects that use it, one click installs do exist on Linux, via the autopackage installer. And they are actually one click too (well, OK, two clicks) because there's no Next->Next->Next style wizards involved. Why not watch the Flash demo to get a feel for how it works (it's a bit out of date now, things are slightly slicker these days).
One of the biggest problems autopackage has is simply that developers don't know about it. Whereas every Linux developer has heard of RPM, virtually none have heard of autopackage because it's so new (it only went stable in April).
If you like what you see there, spread the word or even better, write patches! The best kind of product is the one that sells itself, after all, and whilst autopackage is already quite nice for the end user we're still busy untangling the ball of wool that software distribution on Linux has become.
But only real contributions to the [L]GPL licensed projects, and even then you have to sometimes have to pull teeth to get them (eg, ObjC++ support is still not upstreamed, ditto for the dead symbol stripping).
For western/Latin scripts there is no big deal, the fonts on Linux look just fine as the auto-hinter can cope well most of the time. Certain types of scripts, especially Asian scripts, currently don't work terribly well with the auto-hinter. I believe the FreeType team are working on fixing this, though you get best (and most compatible) results using the real bytecode interpreter.
For what it's worth this patent is owned by Apple, but they are repeatedly refused to license it so it can be used by free software. It's supposed to expire in 2009 or so, I think.
Slashdot Mirror
Where did you get that information? References please. It'd be pretty cool if true (and long overdue!)
No, security isn't an argument, Microsoft is not only catching up fast there but Apple have fucked up time and time again with that (remote code execution via Safari only a couple of days after releasing Tiger? WTF?).
Usability isn't really an argument either. MacOS interface is sufficiently different from Windows - usually for no better reason than "that's how Mac always did it" - that retraining costs would be higher than for Linux.
Not being Microsoft definitely isn't an argument. Apple have an equally crappy reputation for control freakery and general arrogance.
Virtualisation isn't a long term compatibility solution either. You need something like Wine for that - otherwise you will always still have Windows licenses and systems to maintain even if they *are* virtualised. Not to mention the huge RAM overhead it entails.
Put bluntly, there are no reasons for business to migrate to the Mac, and many reasons to avoid it. That's why Apple chase the home/consumer market so aggressively.
I totally agree with the general thrust of your post though, now is the time. But who will run the last mile? Who will step up? I don't know ... we need superheros and they're badly lacking right now.
Anybody can help with this process, by pushing autopackage towards critical mass. That means asking developers of your favourite projects to provide them.
Incidentally, if Asa is reading this, there has been a Firefox autopackage for ages but the Mozilla developers refuse to accept it upstream!
We also provide tools that make Apple-style "weak linking" very easy (that is what relaytool does) and also a dep solver.
In other words, we provide every means of handling dependencies: the Linux way (depsolve), the Windows way (bundle), the Apple way (weak link). Exactly which a package uses is up to the authors: we're still trying to figure out some guidelines on what is best to use.
This is silly. It's been raised on the Ubuntu lists time and time again. Nonetheless, they refuse to enable it, because Canonical can't guarantee security updates for it. That's also silly, in my books, but then I find the whole idea of a Universe repository very silly indeed; it's simply not possible for a distro to ever be 'finished' like that.
Unfortunately, whilst new means of distributing software are being developed, the distribution developers generally strongly dislike them and sometimes go out of their way to cause difficulty for them. At some point there'll probably be a new wave of distros derived from the current ones that take the last "easy steps" to make Linux really usable for family and friends. Hell I'll do it myself one day if need be. Fedora is so close yet so far!
Still ... it's easy for Asa to criticise now. But think about all those years that Mozilla lumbered on with essentially zero popularity outside of the geek world. It wasn't until Firefox (which took years to develop) reached version 1 that things really took off. Linux is still in the Mozilla Seamonkey stage: cute features are being developed but that last stretch hasn't been reached yet. Arguably, it hasn't even been started.
Still, that said, I have been a license fee payer in the past (not now though), and it was worth every penny if only because adverts interrupting dramatic programs totally sucks!
What's more, Windows not having a package manager doesn't mean they're necessarily worse off. Think about it - if the zlib code was in Windows, they could just update the affected DLLs using Windows Update. If it isn't in Windows, then by definition it wouldn't have been packaged anyway.
The scanners can also detect knives and guns, not just explosives .... generally anything hidden under the clothes. It's also possible to hide explosives from animals if you know they may be present in advance.
At this point, I'll say that I work for them as a summer student. QinetiQ are the organisation formerly known as DERA, or the Defence Evaluation and Research Agency. As defence spending has been dropping year on year for a long time now, it was felt it'd be better to privatise the organisation rather than simply let it fade away.
These days, while a large amount of their work still comes from MoD contracts, they're diversifying at a fast rate.
As to whether there's some secret keiretsu involving QinetiQ, Caryle and the Bin Laden family (who IIRC disowned Osama many years ago), well that's a matter for conspiracy theorists and documentary writers. I see a simpler explanation: Carlyle have a history of investing in defence contractors so they know the territory, and they're one of the biggest private equity groups because they have a lot of investments. At some point there will always be overlap, and what you see there says more about yourself than anything else.
Typically open source projects are quite conventional because the people working on them aren't out to take over the world, they want to produce something useful that they know will solve their problems. For companies, they can say "we'll have 20 people work on this for a year" and if the end result sucks and nobody uses it, it just gets thrown in the trash can and never sees the light of day.
When individuals work on open source development the motivations are different. When companies work on open source development, they typically have some near term problem they want solving and "innovation" would get in the way of that because you're just as likely (assuming it's truly new) to end up with a turkey as a golden goose.
All of this is generalisation of course. You can get innovation in Linux, and I'd expect to see more and more of it as core infrastructure issues get solved increasingly rapidly and more developers move out into app development.
The guys original posting was right on the money: people often abuse the word "innovation" especially when talking about technology companies. Microsoft have certain done things very well and popularised them, and yes certainly some wacko obscure package or OS had them first. Great. The same is true of pretty much everything Apple has done too - so why are Microsoft not "innovative" but Apple are? This was the OPs point, and you demonstrated it neatly by using Smalltalk and Manx C as counter examples.
I've seen more than one distro provided security fix be put out for non-existant security issues, that were very obviously non-existant (eg, discussed on the mailing lists and proven to be non-exploitable).
Debian isn't the only group that fixed a non-existant bug (for Wine). Gentoo did it too, for Mozilla. There are probably more examples: these are ones I came across randomly without looking for them.
Sound - fixed in FC4. ALSA dmix takes care of this for sound cards that can't do hardware mixing. It works for every ALSA app, which most programs now support. The "aoss" program can be used for apps which still use OSS (though it should be applied automatically ... expecting users to know this is silly)
Synaptic was never designed to have a good UI, it was designed as a frontend to apt-get. Try autopackage if you want software installs with a simple and straightforward user interface. Yes, not many packages yet. That is teh suck. Ask your favourite projects maintainers to build them!
Applications - you should never have to add items to the menus manually. If you need to do that, it's a bug in the application itself (some apps just don't register menu entries). Why not send a polite email to the maintainer asking them to add a menu entry and icon for their program?
One other person said they had to wait several hours for it to show up, or that they had to restart gnome-panel to make them appear. This is always a bug; the items should appear instantly. Unfortunately the "gamin" server which is replacing FAM has had a lot of teething problems, in my experience. Make sure your system is fully up to date. It's a pretty good demonstration of Spolskis "don't rewrite software" maxim.
Firefox - not much to say here. Yes, it can be slow with lots of tabs. There are a bunch of nasty memory leaks fixed in the "Deerpark" release that should be going stable soon.
Folder Navigation - this is only a problem in Ubuntu, which unilaterally decided to change the file manager so the old window closed itself when a new window was opened. In the "real" version which Fedora uses, they stay open. The downside? If you have deeply nested folders, you get lots of windows. The upside? Easy to have multiple folders open at once. For the next GNOME version the Nautilus browser view is getting much improved: it's likely that Ubuntu will switch to browser mode by default at that time rather than continue to hack spatial mode.
see here
No, that's only the first time, before you have autopackage on your system. After that they're associated with a launcher app in the GUI so when you click it, the file is passed to an intermediary.
If you want to run it from the command line, then it's currently assumed you know what you're doing, but it'd not be hard to switch to an intermediary like with the GUI there too.
As for --noscripts, well, that's great ... who uses that option in day to day life? Nobody, because some packages do depend on scriptlets and will break in mysterious ways if they aren't run.
Google for something called "relaytool", it solves this problem pretty well.
The button order uses the GNOME HIG unless you're running inside KDE, at which point they swap over to be consistent with the rest of the desktop. Unfortunately the screenshots were taken using KDE, I need to get Taj to regenerate those using GNOME.
Yes, absolutely. Actually this camp of people tends to split into two quite different types:
Obviously autopackage will never please the latter type, but this is in my experience a vocal minority. Usually when people say they like apt, what they mean is they like the convenience of the command line for when they know what they want.
There's no reason you could not implement this UI on top of autopackage using a DNS style naming/lookup service. It would not be hard to do, and if anybody is reading this message and wants to help implement it let us know. We already have basic blueprints for such a feature.
Totally. We have a PHP developer who has written some code that auto-selects which packages to show the user based on their User Agent string. I still need to drag it out of him and get it documented, advertised on the website etc. I keep meaning to write an article or somesuch on website design for open source projects; far too many people link directly to their SourceForge download pages which is awful UI.
So there are two types of vendors here: software developers, both open source and commercial, and distribution vendors.
I think it's fair to say that distros like Fedora and Ubuntu will give up yum and apt over their dead bodies. They're unfortunately sold on the idea of centralised packaging.
On the other hand, the "first time setup" procedure isn't all that hard, unfortunately the UNIX non-security system of +x bits gets in the way but after you run your first autopackage succesfully that's no longer an issue. Autopackage is taking off amongst the indie software developer community, especially the open source gaming community. Again we simply need more people - developers are wanted, but any enthusiastic Linux users who want to help spread the word are also quite appreciated and we can put them to work.
Of course, first impressions last a long time ...
For projects that use it, one click installs do exist on Linux, via the autopackage installer. And they are actually one click too (well, OK, two clicks) because there's no Next->Next->Next style wizards involved. Why not watch the Flash demo to get a feel for how it works (it's a bit out of date now, things are slightly slicker these days).
One of the biggest problems autopackage has is simply that developers don't know about it. Whereas every Linux developer has heard of RPM, virtually none have heard of autopackage because it's so new (it only went stable in April).
If you like what you see there, spread the word or even better, write patches! The best kind of product is the one that sells itself, after all, and whilst autopackage is already quite nice for the end user we're still busy untangling the ball of wool that software distribution on Linux has become.
But only real contributions to the [L]GPL licensed projects, and even then you have to sometimes have to pull teeth to get them (eg, ObjC++ support is still not upstreamed, ditto for the dead symbol stripping).
For what it's worth this patent is owned by Apple, but they are repeatedly refused to license it so it can be used by free software. It's supposed to expire in 2009 or so, I think.
I think it more likely that this has more to do with something called "resident set size" than trend setting.