3 ms·

Well, I was prepared to see something like this, unfortunatelly I didn't really had time or desire to write a more detailed response. No, that's not what I mad

by konart 10y ago

Well, I was prepared to see something like this, unfortunatelly I didn't really had time or desire to write a more detailed response. No, that's not what I made of it, but them I went from Ubuntu to Arch becase they desided they are now the coolers kids in the town and started to introduce shit like Unity and other things. Be the time 10.10 came out - I had to rebuild 1/3 of the system to make it as nice (in my opinion) as it should be and as it was up until they decided to fuck it up (again - just my opinion). Anyway - Arch was the best thing I could find among all other distros. Modular approach, KISS, very easy to install and maintain. The problem (both with Ubuntu and Arch, mind you) comes not with what you described as "new shiny things from unproven teams" or "Newer is often not automagically better.". Here is an example for you. At some point Jim was using program A for audio editing and program B for video editing. A used some libA library and B uses libraries libA and libB (among many others). At some point something happened inside the team of libA and now we have libAa and libAb. They have some differences (obviously). Now the teams of A and B have to decided what library to use. Fighting among them leads to new arguments about functionality and other this and two new forks appear. So now we have programs Aa, Ab, Ba and Bb. Now Jim, as a use of their previous versions had to chose what to use from this moment onwards and sometimes, it happens so that he needs all the functionality that B had, but not it is torn between Ba and Bb. So by the end of the day he has two forks of B installed, one fork of A, two libraries that do the same thing and he is praying nothings starts to get in conflict with the others. And this happens all the time. >We've been using and developing with and deploying on Ubuntu for years now. This makes it sound like you are talking about something that works as a server for services or software you deploy. I'm talking about using linux at home as working\media machine, not as a server. The latter has no such problems (not to this extent at least)

oliwarner 10y ago
I don't think you have the correct measure of me. I use Linux everywhere. I'm a user. A developer. An Ubuntu member. An advocate. I help people for free (Oli on Ask Ubuntu and #Ubuntu) and I also professionally deploy desktops and servers and kiosks and single-purpose boxes, and write software at all levels (kernel to user interface). I sympathise with desktop nomads but all desktop environments (closed and open) are opinionated. You didn't like Ubuntu's. Neither did I; I moved to Kubuntu. Literally a single meta-package swap, no rebuilding necessary. I find it curious that you're allowed an opinion about desktops but the developers who write your software aren't about the software they use. Moreover, in a maintained ecosystem (eg Ubuntu) end users don't really have to worry about build deps. Yeah the confusion between (eg) libav and ffmpeg can really draw on but mostly things just work. apt install this and that and it doesn't matter if that's Aa or Ab. As long as A installs the user is happy. It's the maintainer's problem to keep that going. Even on Arch —where you are exposed to more of this— the community is usually pretty decent at fixing builds. Now as a developer (and maintainer) I get pissed off when my libraries change their deps but that really has nothing to do with my operating system, or even the concept of open source. It is what it is and it's built into my workflow.
- konart 10y ago
  I don't even try to measure you (not in any bad way at least :) ) >I find it curious that you're allowed an opinion about desktops but the developers who write your software aren't about the software they use. Well, first of all, I am a developer, just as they are and by any sane logic - they are allowed to have an opinion as much as I am. What you are describing (from my point of view at least) - is something similar to Garbage Collector. Yeah, garbage is not okay, but we have GC to deal with it. My point is - I don't like garbage in my room at all. Even with GC doing it's job - sometimes 'things' do happen. And yes - you are right about the community part. This is one of the best things about linux, actually. Chances are as high as they can be that problem will be reported, documented (in some way) and fixed rather quickly. You can't compare Arch's forum (which did me more help even while I was pretty new to Ubuntu, ironically) to Apple's forums and most of the 'have you tried to reset your Mac's SMC & PRAM?" posts on the web. >to do with my operating system, or even the concept of open source But it's still part of it, face it. The fact that it is built into your workflow does not change this fact. I'm not advocating for moving from open to proprietary, I'm just saying, that some people would rather prefer a system, that offers closed code, that just works. Apple did this and you still have the same opportunity to build and used open source on their system. I had apt-get and pacman, now I have brew. But I don't have to worry about some configs in my system I'd rather not know about at all.
  - oliwarner 10y ago
    > I'm just saying, that some people would rather prefer a system, that offers closed code, that just works. Apple did this Again, I don't see why that only applies to open source. I've implemented both open source and proprietary software that have changed how they work after upgrades. Both have also provided long-term support on older versions to work the old way. When I say I build this into my workflow, the basis for this is understanding how the software I depend on is maintained. Things like Ubuntu, Django, Nginx, Postgres all have long and predictable lives if you opt into that. I can deploy something on 16.04 today an still deploy it on 16.04 in 2021. The infrastructure will have received security updates, but the APIs remain static. My software will continue to work as it always did. That's also how you'd aim to do it with proprietary software but you can still make bad decisions. If you insist on staying on the very latest everything (instead of opting for long term support versions) you will have to test and upgrade your application a lot more frequently. Just to round on Apple here, they're not perfect at this either. They make no commitment to how long their software will be supported and on average versions of OS X are supported around ⅔ the time Ubuntu LTS versions are. Ubuntu (or RHEL) are far better bases if you require a predictable and long-lasting product.

by konart 10y ago

oliwarner 10y ago

I don't think you have the correct measure of me. I use Linux everywhere. I'm a user. A developer. An Ubuntu member. An advocate. I help people for free (Oli on Ask Ubuntu and #Ubuntu) and I also professionally deploy desktops and servers and kiosks and single-purpose boxes, and write software at all levels (kernel to user interface). I sympathise with desktop nomads but all desktop environments (closed and open) are opinionated. You didn't like Ubuntu's. Neither did I; I moved to Kubuntu. Literally a single meta-package swap, no rebuilding necessary. I find it curious that you're allowed an opinion about desktops but the developers who write your software aren't about the software they use. Moreover, in a maintained ecosystem (eg Ubuntu) end users don't really have to worry about build deps. Yeah the confusion between (eg) libav and ffmpeg can really draw on but mostly things just work. apt install this and that and it doesn't matter if that's Aa or Ab. As long as A installs the user is happy. It's the maintainer's problem to keep that going. Even on Arch —where you are exposed to more of this— the community is usually pretty decent at fixing builds. Now as a developer (and maintainer) I get pissed off when my libraries change their deps but that really has nothing to do with my operating system, or even the concept of open source. It is what it is and it's built into my workflow.

konart 10y ago
I don't even try to measure you (not in any bad way at least :) ) >I find it curious that you're allowed an opinion about desktops but the developers who write your software aren't about the software they use. Well, first of all, I am a developer, just as they are and by any sane logic - they are allowed to have an opinion as much as I am. What you are describing (from my point of view at least) - is something similar to Garbage Collector. Yeah, garbage is not okay, but we have GC to deal with it. My point is - I don't like garbage in my room at all. Even with GC doing it's job - sometimes 'things' do happen. And yes - you are right about the community part. This is one of the best things about linux, actually. Chances are as high as they can be that problem will be reported, documented (in some way) and fixed rather quickly. You can't compare Arch's forum (which did me more help even while I was pretty new to Ubuntu, ironically) to Apple's forums and most of the 'have you tried to reset your Mac's SMC & PRAM?" posts on the web. >to do with my operating system, or even the concept of open source But it's still part of it, face it. The fact that it is built into your workflow does not change this fact. I'm not advocating for moving from open to proprietary, I'm just saying, that some people would rather prefer a system, that offers closed code, that just works. Apple did this and you still have the same opportunity to build and used open source on their system. I had apt-get and pacman, now I have brew. But I don't have to worry about some configs in my system I'd rather not know about at all.
- oliwarner 10y ago
  > I'm just saying, that some people would rather prefer a system, that offers closed code, that just works. Apple did this Again, I don't see why that only applies to open source. I've implemented both open source and proprietary software that have changed how they work after upgrades. Both have also provided long-term support on older versions to work the old way. When I say I build this into my workflow, the basis for this is understanding how the software I depend on is maintained. Things like Ubuntu, Django, Nginx, Postgres all have long and predictable lives if you opt into that. I can deploy something on 16.04 today an still deploy it on 16.04 in 2021. The infrastructure will have received security updates, but the APIs remain static. My software will continue to work as it always did. That's also how you'd aim to do it with proprietary software but you can still make bad decisions. If you insist on staying on the very latest everything (instead of opting for long term support versions) you will have to test and upgrade your application a lot more frequently. Just to round on Apple here, they're not perfect at this either. They make no commitment to how long their software will be supported and on average versions of OS X are supported around ⅔ the time Ubuntu LTS versions are. Ubuntu (or RHEL) are far better bases if you require a predictable and long-lasting product.