Does somebody know who is the speaker? Didn't see it on the blip.tv page.
Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
81–90 of 97 posts
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#82If history is any evidence, nothing. :P
Actually, as someone who has used Linux as desktop software since 1996, I would say the exact opposite: it's making rapid progress compared to where it was once. Perhaps it still hasn't quite caught up, but I'm relatively certain that soonish, it will be 'good enough' for an ever-larger segment of the population. It's already 'good enough' for a lot of people.
it will always "soon" be ready for large-scale adoption.
But it never will.
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#83Does somebody know who is the speaker? Didn't see it on the blip.tv page.
Bryan Lunduke - sorry I saw it on the video now.
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#84Earlier quoted context omitted.
Well, like Arch Linux's Pacman and AUR? :) I found Pacman to be easy and simple--on the same level as APT, and when the binary package doesn't do what you want, packing your own package is really easy. http://wiki.archlinux.org/index.php/Pacman http://wiki.archlinux.org/index.php/Arch_Build_System
upvoted for pacman. I actually have only tried arch at a friend's place, because for some anal reason Arch does not provide livecds. Only a command shell from where you must build your system up, which is quite a pain. But I have only heard good things about pacman (and it's ultra simple package format). It enables Arch's rolling releases model, which means that you are always up2date without having to go from Beserk…
As someone who has run Arch on their main PC for a year+, let me tell you it's not all roses. pacman may be simple, but it lacks many features you have come to expect; don't be surprised when everything on your system breaks when you pull in an updated library. Don't be surprised when pacman pulls in a new kernel without noticing, your machine fails to boot because it has nuked all of your old kernel modules.
While I agree that the rolling release model is attractive, it requires a much more robust package management system to be practical for people who do not live on the bleeding edge 24/7.
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#85Earlier quoted context omitted.
Actually, as someone who has used Linux as desktop software since 1996, I would say the exact opposite: it's making rapid progress compared to where it was once. Perhaps it still hasn't quite caught up, but I'm relatively certain that soonish, it will be 'good enough' for an ever-larger segment of the population. It's already 'good enough' for a lot of people.
it will always "soon" be ready for large-scale adoption. But it never will.
Until it is. In 2006 we had Ubuntu on all computers at the company I worked for, because most of the people were either 1) developers and used it anwyway or 2) didn't really need more than a browser and openoffice anyway, and were thus perfectly content with it.
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#86Sell Ubuntu (and other apps like OOo, Gimp, etc) for a nominal $9.95
Give two options in the download area of your software, one green button with a $9.95 download and one blue button for a free download. Both pointing to the same package.
If you want to contribute to open source, click the green one.
Also sell it on best buy and walmart for $9.95 to reach the non-tech-savvy audience.
Even if they drop it on the trash can when they get home. At least some money goes to the pockets of the open sourcerers, which is better than none.
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#87The audio situation is a total debacle. n-1 of the sound systems need to be killed so we can focus on making the remaining one work really well. It's really funny that this is his first point, because I ran into it just two days ago... the microphone jack on my laptop, which worked fine in Ubuntu hardy, intrepid, and jaunty, no longer works in karmic thanks to the upgrade to pulseaudio (bug has existed in launchpad s…
It is hard to believe that sound can be so broken, after all these years (and looking at the huge strides other parts of the desktop have made). If Ubuntu wants to be the uber-friendly, runs anywhere (just works!) distro, they need to avoid these types of regressions from one version to the next. I know they're not in charge of all the upstream work, but they are the ones that make the decision on what version of pul…
I think Fedora has led on the bleeding edge of pulseaudio. Ubuntu apparently had a borked setup in one version of Ubuntu, but the same code was running well on Fedora.
Having said that, pulseaudio really seems to bring out the cranks and probably most of the issue is that it's become something that it's okay to complain about, rather than something that people get behind and fix.
It is however clearly the future and like many things in Linux ripping out mature half-solutions to replace them with newer full solutions is going to cause regressions for some. As long as Linux is making progress on average then it's all part of the game.
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#88Earlier quoted context omitted.
Meh, from a source point of view, once I have a debian/ directory, with a properly set up rules file, building becomes trivial. Then it is matter of generating a package per-distro/version with the right environment. This could be very well done in an automated manner and a few vms.
Which is exactly what the build service gives you...
My bad, I was under the impression that it was an RPM only thing.
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#89I think what Linux really needs is to embrace some way of getting software outside apt/yum. Having to go through the package managers forces you to be an administrator to install software, and the developer and user have no say in which version of the application you get. I think Linux distributions should be platforms which developers can develop applications for which they can distribute however they wish. Then use…
Every binary distro I've ever used (SUSE, Debian, Ubuntu, RHEL and Fedora) came with a little GUI that let you install packages without going through a repository. Just download the .deb/.rpm and double click on it. This is how a lot of projects deliver their latest builds. If you're talking about a unified package format (it doesn't seem like it) then thats a completely different issue. As for 'stand-alone' applicat…
Unfortunately this isn't used enough. It is not used by Firefox and Thunderbird. Instead they provide .tar.bz2 files.
I was pleasantly surprised by skype and chrome, who actually provide rpms and debs. Nice!
Open Office gave me a tarball with a myriad of debs. Not the nicest kind of packaging.
Unfortunately the distributions performs their own packaging of a lot of these applications which may give some people the idea that they should use the version packaged by the distribution. The distributions should really stop doing this and refer people to the official packages instead. Otherwise users will be stuck on old versions.
I also don't know how well this kind of delivery mechanism works with automatic updates. Do the external packages get updated in the same way as the packages delivered by the distribution or does anything like Sparkle exist for Linux?
Re: Why Desktop Linux (Still) Sucks. And What We Can Do To Fix It.
#90The easiest problem to tackle is .RPM vs .DEB debate that should have ended about 3 years ago. If the LSB had said .DEB it might have happened, but since the "official" standard and the actual majority are diametrically opposed it doesn't want to happen. And of course the filesystems don't perfectly match across distros.
The .rpm vs .deb debate is a fallacy. The real issue is that when packaging for say debian and RHEL you have to care about different glibc, different compiler versions with potentially different ABI, different filesystem conventions, different scripts for post install, etc... The format in which the files are packaged is the least of the issues compared to that. For example, packaging for opensuse once you have a pac…
I hear what you are saying, but we can reduce the differences between build systems while still using different targets.
I do a lot of work with OpenEmbedded, every distro image you create is for a different hardware platform, using different libraries, different tools, etc. But it is a unified build system. So I can say use this version of glibc and spit out the files in that folder, and with very minor tweaks I can use a completely different version of glibc and a different file structure for another image. If we had a unified dependency/build system across distros, we could have completely different contents while having relatively straightforward customization because if you knew one system, you'd know them all.