91–100 of 103 posts
Earlier quoted context omitted.
If you really want to do that you should statically link it.
A wonderful idea. Let me just statically link an LGPL library into my Commercial application...
There is a lot about GTK I like; it's a C library making compatibility easier[1], it always seemed way faster (less memory bloat?) than QT, and while the widget-packing/nesting style was somewhat ugly, I found it surprisingly easy to write. I was even enjoying Vala. While it was obviously a young language, it had a lot of interesting ideas. Then we got the new 3.x version of GTK with its "lets rewrite everything for…
> The last straw was when they decided to join Pottering's "lets forget Unix and make Linux into Windows" crusade. Could you give a little more background about this? (True curiosity, I don't doubt that what you say is true!)
"Turning Linux into Windows" is hyperbole, though; the most used and developed-on non-mobile Unix -- Mac OS X -- is similarly epicurean, and blithely makes use of tightly coupled components designed to work together, to deliver a smooth easy-to-manage experience. And it's eating Linux's lunch.
Earlier quoted context omitted.
"It's unfortunate that Linux and/or Linux distributions have not yet solved the problem of supporting parallel versions of dependencies." Uh, they have. For ever. I have parts of boost 1.49, 1.53, 1.54 and 1.55 together on my system. I have GTK2 and GTK3 together on my system. I have Qt3, Qt4 and Qt5 together on my system. Python2 and Python3. libpoppler19, libpoppler44 and libpoppler46.
Which distribution supports it in general? Sure, there are particular instances of it being supported, but it's not supported in general.
Earlier quoted context omitted.
I remember when Gtk 2.0 came out. IIRC, at the time, Qt seemed to be bloated and slow compared to Gtk, but Gtk had a lot of breaking changes and was more work to program with. I was unimpressed with having to constantly figure out how to update my Gentoo system when Gtk kept moving functions from one library to another, which required hacking in symlinks to point to new libraries that programs required. It was a real…
Er, what? I ran Gentoo from 2001 until mid-2013, and I was a maintainer and core developer of parts of Xfce (a Gtk-based desktop environment) from early 2004 until late 2009, and I have no idea what you're talking about. Gtk was a pain to develop with, sure, but only due to the awkwardness of GObject's attempts to build an OO system on top of C. From a user perspective, I never saw the problems you're describing. Eve…
There is a lot about GTK I like; it's a C library making compatibility easier[1], it always seemed way faster (less memory bloat?) than QT, and while the widget-packing/nesting style was somewhat ugly, I found it surprisingly easy to write. I was even enjoying Vala. While it was obviously a young language, it had a lot of interesting ideas. Then we got the new 3.x version of GTK with its "lets rewrite everything for…
> The last straw was when they decided to join Pottering's "lets forget Unix and make Linux into Windows" crusade. Could you give a little more background about this? (True curiosity, I don't doubt that what you say is true!)
Yes, there's a bit of hyperbole in that statement, but there is a problem there. Pottering has pushed a very "our way and no other" attitude, even when other people have requirements that aren't met by systemd.
Worse, the tight-coupling between components is a perfect example of the "embrace and extend" tactic. The monopoly position systemd currently enjoys has successfully been used to extend into a disturbing number of other components[1].
As for unix-vs-windows - switching to a windows-style binary log and rewriting an inetd into a mandatory "SvcHost.exe" for linux is bad enough, but the real issues is the removing of well-defined barriers between components.
Pottering's hatred scripts is a problem, because using scripts as the "glue" in unix is one of the most important features of unix. Keeping many of the the interactions between components in an open and readable format has forced developers to create (and deal with) methods of API that can actually be extended beyond the original project. Systemd returns to the windows style of just making function calls into the current implementation. Being forced to, for example, listen on a unix socket for a command works easily with anything, even into the future. Requiring that same message be sent by calling some function encourages linking to extra libraries and makes interaction from scripts much more difficult.
This isn't about any technical benefits; keeping the IPC between components open and well-defined is even more important than access to the source code itself if we are to maintain an ecosystem of Free Software. For those of us that would like to have a Free (as in freedom) Software ecosystem survive the current War On General Purpose Computing[2], the campaign by the pro-systemd people is, frankly, terrifying. Sometimes there are more important goals than "faster" or "cleaner API" or "easier to write". Keeping the OS - both the kernel and system-utils - open, free, and interchangeable needs to be a high priority goal, or we will lose the progress the Free Software community has made over the last ~decade.
[1] http://www.phoronix.com/scan.php?page=news_item&px=MTczNDk
Earlier quoted context omitted.
Not everybody likes Qt's CLA.
And by "Not everybody" you of course mean "People who don't know any better", right? The Qt legal situation has changed a lot lately, especially since Nokia went out of the picture. Look it up: https://qt-project.org/legal.html
Earlier quoted context omitted.
Er, what? I ran Gentoo from 2001 until mid-2013, and I was a maintainer and core developer of parts of Xfce (a Gtk-based desktop environment) from early 2004 until late 2009, and I have no idea what you're talking about. Gtk was a pain to develop with, sure, but only due to the awkwardness of GObject's attempts to build an OO system on top of C. From a user perspective, I never saw the problems you're describing. Eve…
I'm talking about the change from Gtk1.0 to Gtk2.0 (or that's what I remember mostly). I gave up on Gentoo around 2001 or so. Things were better when I left, but there was still breakage whenever I did a world-update. I had fallen into the lazy habit of not updating often enough which contributed to the problem, but still, the promise was that all you had to do was to do a world-update and everything would work fine.…
Earlier quoted context omitted.
Er, what? I ran Gentoo from 2001 until mid-2013, and I was a maintainer and core developer of parts of Xfce (a Gtk-based desktop environment) from early 2004 until late 2009, and I have no idea what you're talking about. Gtk was a pain to develop with, sure, but only due to the awkwardness of GObject's attempts to build an OO system on top of C. From a user perspective, I never saw the problems you're describing. Eve…
I'm talking about the change from Gtk1.0 to Gtk2.0 (or that's what I remember mostly). I gave up on Gentoo around 2001 or so. Things were better when I left, but there was still breakage whenever I did a world-update. I had fallen into the lazy habit of not updating often enough which contributed to the problem, but still, the promise was that all you had to do was to do a world-update and everything would work fine.…
I don't recall the stability of the 2.0.x series, though: it's possible they didn't get things right and were still making breaking changes even though it was the stable series. I don't remember that being a problem, but I'll admit my memory of that period isn't perfect.
I do remember some app developers prematurely upgrading and releasing versions that depended on early development releases of 2.0 (and later, on the 2.1.x unstable series), which often did cause breakages. But that was really the app developer's fault for depending on versions that made no API/ABI guarantees.
Earlier quoted context omitted.
A wonderful idea. Let me just statically link an LGPL library into my Commercial application...
Sure, just relicense your application under the GPL. You're getting these libraries for free. If you're not at all willing to contribute back, then you're obviously not the target audience.
Unfortunately, convincing the people who write my paychecks, VMware, to contribute Workstation and Player to the Open Source community seems to be a pretty big stretch.
I tried Qt and liked the fact that it had good libraries built in (using the provided networking library v/s using libsoup with Gtk+)
In my opinion Gtk+ with C is a big pain but Vala feels natural and should've been pushed instead of JavaScript by the gnome guys.