4 ms·

Personally, it seems that we -- as for people appropriately inclined -- have reached the point where you just want _some_ platform to run Debian/Ubuntu: if it's

by yason 17y ago

Personally, it seems that we -- as for people appropriately inclined -- have reached the point where you just want _some_ platform to run Debian/Ubuntu: if it's OSX, cool; if it's native Ubuntu, okay then, too, as long as it works well enough with the hardware. I dumped OSX a couple of years ago and a major part was the package management trouble. I need all the basic open-source software as well-laid as in Ubuntu/Debian. I want them to be compatible, familiar, hopefully in the nice GNU flavor I'm used to, and preferably as the de facto standard for the system I'm using so that I won't run into conflicts with the system software itself. For me in 2006/2007, DarwinPorts/MacPorts/Fink/whatever didn't cut it. They weren't as up to date nor as extensive as Ubuntu/Debian repositories, and I was always feeling something was lacking in their overall integrity. In Ubuntu, it's the native software stack and everything just clicks together. I think it would be really great if you could use a Mac with native OSX to run your Debian and GNU stuff as well as Ubuntu does. I doubt Mr. Jobs would agree, though.

unalone 17y ago
KDE makes their stuff available for OS X. One day I tried Amarok, partly because a Linuxing friend used it and recommended it, mainly because the Mike Oldfield song of the same name is my favorite song of all time. It installed a bunch of crap on my computer, added a folder directly to my root user, took a minute to launch, displayed a huge logo while it was launching, presented me with the ugliest interface I've ever faced on this operating system, took hours to find my music, then crashed when I tried to play a song. Apple is of the opinion that its programs have to be unique and special. After my experience with KDE-on-Mac, I'm going to agree and say that if Linux things ran instantly on the Mac, the quality of experience for anybody who made an effort to run them would drop sharply. I'm fine with the App system on the Mac. It's ultrasimple. Package management is a teeny bit simpler, but it's not enough for me to bother over.
- antonovka 17y ago
  I'm fine with the App system on the Mac. It's ultrasimple. Package management is a teeny bit simpler, but it's not enough for me to bother over. I'm not sure it's actually simpler; as a software author, my experience has been: If I want to release something for the Mac, I post a dmg containing a dragable application; and even the most non-technical user can download and install it immediately. Sparkle provides automatic updates via my website; users gets the latest versions whenever they want them, I don't have to do anything complicated. If I want to release something for the UNIXes, I provide a set of autoconf scripts and a make-based build system (or one of the recent alternatives, or a Python egg, or a Ruby gem), hope that the package management systems pick it up during their next release cycle, wind up in an argument with Debian over OpenSSL+GPL licensing compatibility, and see my software get shipped with half the featured turned off and a ridiculous number of local hacks applied, including all-too-regularly replacement of a working library dependency with something that doesn't work (but Debian likes it more). The average end-user doesn't see my updates for months or years, the software is missing features and locally modified, and I have to wonder: Why couldn't I just give them something that they could drag to their applications folder?
  - nuclear_eclipse 17y ago
    You could always provide your own package repository and/or build your own packages. It's not terribly difficult, and certainly isn't any more difficult that maintaining your own auto-update mechanism anyways. And if you have your own package repo, users will get updates from your repository whenever they update their system...
    - blasdel 17y ago
      You still have the problem of having your package's dependencies be broken/mutilated/ancient -- the only solid way to get around it is to statically link with your own unfucked builds, but that isn't always possible.

by yason 17y ago

unalone 17y ago

KDE makes their stuff available for OS X. One day I tried Amarok, partly because a Linuxing friend used it and recommended it, mainly because the Mike Oldfield song of the same name is my favorite song of all time. It installed a bunch of crap on my computer, added a folder directly to my root user, took a minute to launch, displayed a huge logo while it was launching, presented me with the ugliest interface I've ever faced on this operating system, took hours to find my music, then crashed when I tried to play a song. Apple is of the opinion that its programs have to be unique and special. After my experience with KDE-on-Mac, I'm going to agree and say that if Linux things ran instantly on the Mac, the quality of experience for anybody who made an effort to run them would drop sharply. I'm fine with the App system on the Mac. It's ultrasimple. Package management is a teeny bit simpler, but it's not enough for me to bother over.

antonovka 17y ago
I'm fine with the App system on the Mac. It's ultrasimple. Package management is a teeny bit simpler, but it's not enough for me to bother over. I'm not sure it's actually simpler; as a software author, my experience has been: If I want to release something for the Mac, I post a dmg containing a dragable application; and even the most non-technical user can download and install it immediately. Sparkle provides automatic updates via my website; users gets the latest versions whenever they want them, I don't have to do anything complicated. If I want to release something for the UNIXes, I provide a set of autoconf scripts and a make-based build system (or one of the recent alternatives, or a Python egg, or a Ruby gem), hope that the package management systems pick it up during their next release cycle, wind up in an argument with Debian over OpenSSL+GPL licensing compatibility, and see my software get shipped with half the featured turned off and a ridiculous number of local hacks applied, including all-too-regularly replacement of a working library dependency with something that doesn't work (but Debian likes it more). The average end-user doesn't see my updates for months or years, the software is missing features and locally modified, and I have to wonder: Why couldn't I just give them something that they could drag to their applications folder?
- nuclear_eclipse 17y ago
  You could always provide your own package repository and/or build your own packages. It's not terribly difficult, and certainly isn't any more difficult that maintaining your own auto-update mechanism anyways. And if you have your own package repo, users will get updates from your repository whenever they update their system...
  - blasdel 17y ago
    You still have the problem of having your package's dependencies be broken/mutilated/ancient -- the only solid way to get around it is to statically link with your own unfucked builds, but that isn't always possible.