I can only agree. GNOME 3 was a bit rough around 3.0/3.2 and wasn't really that great until 3.8/3.10. Unfortunately, it was in the early days when a lot of people tried GNOME 3 for the first time. Debian with GNOME 3.14 will be a great desktop experience.
systemd has to be pinned to -1 or your servers will get upgraded to it without any interaction from your part.
Of course it gets installed, it's the default init system in Jessie. Most users would expect to have it installed when upgrading, considering that it's a major new feature in Jessie and meant as a replacement for sysvinit.
Beware also that Apache configurations change.
Apache went from 2.2 to 2.4, which in Apache speak is pretty much a major version change. There were lots of changes in 2.4, especially making the event-based mpm the default. But there's also a lot of other changes so expect that you have to go through and possibly change a lot of configuration. I also have a number of custom Apache modules that had to be partly rewritten. But once that was done things have been running just fine.
The UI was redesigned but it still has the capabilities of the old UI, if you're willing to look for things in another place. Most things were moved to the app menu and the drop-down menus in the top-right corner of the viewer window. Keyboard shortcuts are of course still there.
GNOME applications works just fine with other desktop environments and window managers. What used to be the biggest concern, the app menu, is no longer handled by adding a separate menu bar in the window with just for that menu. Instead, most applications show it as a button in the headerbar when not run within GNOME.
OS X actually has perfectly fine support for shared libraries. They are supposed to be installed under/Library/Frameworks, and there are some applications that do that. There's no reason why they couldn't do that on iOS as well, just let developers share frameworks on the App Store and build a mechanism into the App Store where an app can require other apps or frameworks.
Non system libraries are statically linked.a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.
Managing shared libraries across applications works fine in a GNU distribution where the distribution takes responsibility for all applications. With Apple's approach there's no good way to manage this, different applications might use their own specialized version of the library. At most you might have an opt-in system where developers can register the libraries they are using and the version they require, and have the system download and manage them for them.
If "you" are the legal department for a company with 10,000 developers, the GPL is scary. You can either blanket-ban GPL code, and make your life easy, or create a system for separately evaluating the use of each and every piece of GPL code you allow in, plus some auditing process to catch cheaters (who check in GPL code as their own work, which happens).
Cloud services companies usually go with the latter: because you don't have to share your code if you don't distribute it, the payoff is good to allow use of GPL code, and police the corner cases where you do distribute code. Blanket bans on GPL code are still common at old-school software companies.
Most non-free licenses are quite scary too, but they often get a pass since they are not that open to begin with.
You can actually share an RCS repo just fine since it does file locking. It's actually quite common even nowadays for configuration files in cases where a larger configuration management system is overkill.
Very few people actually know their version control software. Most people know the basic commands, and that's the case for pretty much all of them. Git is not much different in that regard.
Do they still "look just like" or are they "the same thing?" It used to be very easy to distinguish Qt applications on OS X when I used to use it a couple of years ago. The widgets looked very similar but you could instantly recognize that they were not quite right. It would be nice to know if the situation has improved.
It is a shame that this got submitted before we actually published the code. It is Easter and many of our engineers are taking these days off.
The release notes are also incomplete and not ready for publishing
Miguel
That means very little in practice. You can be sued for patent infringement by anyone for more or less anything. A license will not help you with that.
That was actually true for Java too. Unfortunately Java development also slowed down significantly once it became mature, around 5.0-6.0. Scala is where most of the interesting stuff in Java is going on these days.
For RAD I've had some good experiences in the pas with RealBasic (renamed to Xojo some time ago). At the time the GNU/Linux support was quite ok but they haven't really kept up. 64 bit is still missing for example so running anything you build with it will require a couple of 32 bit system libraries to be installed.
Javascript itself is a plugin. Any concept of distinction is flawed. Lets say in the panaea of worlds, Oracle gave Java tech and all its reference impl's away for free BSD styled. What if anything would be the harm of writing browser scripts in Java vs. Javascript vs. go vs..net-whatever, etc.. if every single browser developer had access to native embeddable runtimes embedded into the tool?
If it was built into every single browser then things would be different. But that doesn't matter right now because it's not. It doesn't matter how great of a technology it is if you can't run it on an iPhone.
Everything that is a plugin is more or less unsuitable for the web, especially now when more (or even most) web traffic comes from mobile computers where plugins are sometimes not even possible to use.
Slashdot Mirror
I can only agree. GNOME 3 was a bit rough around 3.0/3.2 and wasn't really that great until 3.8/3.10. Unfortunately, it was in the early days when a lot of people tried GNOME 3 for the first time. Debian with GNOME 3.14 will be a great desktop experience.
Why would you pin systemd to -1 if you use it to build debs? What part of systemd prevents you from building debs?
systemd has to be pinned to -1 or your servers will get upgraded to it without any interaction from your part.
Of course it gets installed, it's the default init system in Jessie. Most users would expect to have it installed when upgrading, considering that it's a major new feature in Jessie and meant as a replacement for sysvinit.
Beware also that Apache configurations change.
Apache went from 2.2 to 2.4, which in Apache speak is pretty much a major version change. There were lots of changes in 2.4, especially making the event-based mpm the default. But there's also a lot of other changes so expect that you have to go through and possibly change a lot of configuration. I also have a number of custom Apache modules that had to be partly rewritten. But once that was done things have been running just fine.
The UI was redesigned but it still has the capabilities of the old UI, if you're willing to look for things in another place. Most things were moved to the app menu and the drop-down menus in the top-right corner of the viewer window. Keyboard shortcuts are of course still there.
Or use something like FAI. It's widely used in larger deployments and allows you to customize as much as you want of the system at install time.
GNOME applications works just fine with other desktop environments and window managers. What used to be the biggest concern, the app menu, is no longer handled by adding a separate menu bar in the window with just for that menu. Instead, most applications show it as a button in the headerbar when not run within GNOME.
The software probably works just fine. It's interacting with Apple's online services that doesn't work anymore.
Not to mention the Windows-like version numbering scheme!
...gnu11 instead of the older gnu89
Obviously!
Blame ISO. The gnu compiler modes named in the same scheme as the corresponding versions of the C programming language, C89, C99, C11.
OS X actually has perfectly fine support for shared libraries. They are supposed to be installed under /Library/Frameworks, and there are some applications that do that. There's no reason why they couldn't do that on iOS as well, just let developers share frameworks on the App Store and build a mechanism into the App Store where an app can require other apps or frameworks.
Nowadays that's more or less the default scenario.
Non system libraries are statically linked .a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.
Managing shared libraries across applications works fine in a GNU distribution where the distribution takes responsibility for all applications. With Apple's approach there's no good way to manage this, different applications might use their own specialized version of the library. At most you might have an opt-in system where developers can register the libraries they are using and the version they require, and have the system download and manage them for them.
If "you" are a one-man shop, that's fine.
If "you" are the legal department for a company with 10,000 developers, the GPL is scary. You can either blanket-ban GPL code, and make your life easy, or create a system for separately evaluating the use of each and every piece of GPL code you allow in, plus some auditing process to catch cheaters (who check in GPL code as their own work, which happens).
Cloud services companies usually go with the latter: because you don't have to share your code if you don't distribute it, the payoff is good to allow use of GPL code, and police the corner cases where you do distribute code. Blanket bans on GPL code are still common at old-school software companies.
Most non-free licenses are quite scary too, but they often get a pass since they are not that open to begin with.
You can actually share an RCS repo just fine since it does file locking. It's actually quite common even nowadays for configuration files in cases where a larger configuration management system is overkill.
Very few people actually know their version control software. Most people know the basic commands, and that's the case for pretty much all of them. Git is not much different in that regard.
Do they still "look just like" or are they "the same thing?" It used to be very easy to distinguish Qt applications on OS X when I used to use it a couple of years ago. The widgets looked very similar but you could instantly recognize that they were not quite right. It would be nice to know if the situation has improved.
Looks like that's the case
It is a shame that this got submitted before we actually published the code. It is Easter and many of our engineers are taking these days off.
The release notes are also incomplete and not ready for publishing
Miguel
That means very little in practice. You can be sued for patent infringement by anyone for more or less anything. A license will not help you with that.
That was actually true for Java too. Unfortunately Java development also slowed down significantly once it became mature, around 5.0-6.0. Scala is where most of the interesting stuff in Java is going on these days.
From the linked release notes:
THIS IS A DRAFT OF THE 4.0 RELEASE NOTES
I also can't find the 4.0 tarballs on the download page, which still says that 3.12.1 is the latest Mono release.
For RAD I've had some good experiences in the pas with RealBasic (renamed to Xojo some time ago). At the time the GNU/Linux support was quite ok but they haven't really kept up. 64 bit is still missing for example so running anything you build with it will require a couple of 32 bit system libraries to be installed.
Windows won using abusive monopolist tactics.....
Ehm, technically you can't really use "abusive monopolist tactics" until after you've "won."
I don't know exactly what "Pale Moon" is but the next ESR will be Firefox 38 in about six weeks.
Java became de-facto monoculture, there is only one widely used implementation.
You're talking about Android, right?
Javascript itself is a plugin. Any concept of distinction is flawed. Lets say in the panaea of worlds, Oracle gave Java tech and all its reference impl's away for free BSD styled. What if anything would be the harm of writing browser scripts in Java vs. Javascript vs. go vs. .net-whatever, etc.. if every single browser developer had access to native embeddable runtimes embedded into the tool?
If it was built into every single browser then things would be different. But that doesn't matter right now because it's not. It doesn't matter how great of a technology it is if you can't run it on an iPhone.
Everything that is a plugin is more or less unsuitable for the web, especially now when more (or even most) web traffic comes from mobile computers where plugins are sometimes not even possible to use.