Bugs were introduced (probably not on purpose) into GTK2 after GTK3 was released, and those bugs will never be fixed. For example I periodically get bug reports for one of my applications which I’ve traced down to GtkFileChooserButton and it’s a known issue noone will fix in GTK2.
Gtk2 is still maintained and as far as I know there are no immediate plans to stop that. We had a gtk2 release just last month which fixed eight bugs.
Huge parts of GTK2 have been deprecated, for example:
The horizontal/vertical Box layout scheme, which is how you were supposed to do all layouts in GTK2, and despite the deprecation warnings from the compiler there has been no alternative layout mechanism identified in the documentation.
The entire thread API, which is at the centre of any multi-threaded application. I don’t know if this was replaced with something else or dropped completely.
The GtkVBox/GtkHBox classes are deprecated but the documentation names several alternatives, the primary one being GtkGrid which combines the functionality of both classes.
I don't know what he means by the thread API. The GThread API is not going anywhere if that's what he mean.
The new library is clearly unfinished. For example the GtkAboutDialog is simply broken in the current version of GTK3.
Not sure what he means here. As far as I know it's used by several applications.
Serious bugs in GTK3 are ignored. For example I spent a day researching why they broke the scrollbars in GTK3, found that it was probably done accidentally (the new functionality doesn’t fit even their own designs), filed a bug, and five months later – still not so much as an acknowledgement that this is a problem.
I completely agree that this is a problem. The team developing and maintaining Gtk+ is understaffed and this is an unfortunate side affect.
GTK widgets don't have any style at all, it's all done via css themes. GTK does ship with the Adwaita theme by default, early versions of gtk3 did not do that and could look very badly if a theme was not installed.
Please correct me if I'm wrong but as far as I know gedit's GUI redesign did not remove any features. Some of the visual clutter was removed, like the toolbar buttons from where you could cut, copy and paste. There are of course other ways to access those features.
They don't use gconf anymore, they switched to dconf a couple of years ago. And a lot of settings that can't be accessed from the settings app can be accessed from the GNOME tweak tool, which is also a GUI.
CSD has led to many improvements. Just look at the gedit screenshot you linked to. Since we're able to reuse the title area for widgets we don't have to put a big toolbar under it. The editor actually has more space now compared to the old UI without loosing any features.
I'm a GNOME user and I want would certainly appreciate the new way that the settings looks. It looks like an improvement over the old icon grid where you had to go back and forth just to get to another settings pane.
You run out of capacity on the database server. You set up another one and now you have two. Problem solved. I see it all the time. They have lots of load balanced web servers handling all the front end traffic, but just one monolithic database server in the back that is holding everything back.
Well, being able to scale horizontally is still useful even if you're a small player. Just being able to fire up a second database host and automatically scale up is wonderful for the few times you're actually running out of capacity. Being able to scale up with little effort doesn't mean that you have to scale up big.
The Oklahoma Employment Security Commission clearly don't pay for an update themself. Windows Server 2003 has been end of life and unsupported for quite some time now.
All users have to do is upgrade to the latest version and they will continue to get patches. This will only affect users running old versions of IE on versions of Windows that can run a newer version.
They don't want to encourage anyone to use Vista anymore. It's a rather old OS that is running out of support next year so they do as little as possible and only support IE 9 on Vista until then.
Journald does compression and the structure allows it to actually verify that the logs are sound. Remember that logs can be damaged for multiple reasons. Bugs are of course one reason but the more scary reason is tampering. Syslog has absolutely nothing that prevents tampering with logs. Everything that is submitted to syslog goes in, there is no verification that it's even the correct program. Play around with the logger command on a Linux box and you will be scared. Journald on the other hand actually verifies that the data that goes into the logs are from the correct sender and that once they have been entered you can verify that they have not been tampered with.
What does that even mean? When you enable syslog forwarding the journal will send it to syslog directly without going into the journal. You can even disable the journal log if you don't want it and only want to rely on syslog. So there is no binary log that can "crap out". It just sends it off to the syslog, just like sysvinit handled syslog.
That's because it's not related to init. Init is one subsystem. systemd, being a process manager, doesn't care if init is included or even when it is started. Once it's started, the communication between the parts are within the systemd communication channels (increasingly). This is what makes it monolithic. SMH
Please correct me if I'm wrong here but what process manager are you talking about? Pid 1 on Ubuntu 14.04 is upstart and it owns both of those two services. They are as far as I can see running completely independent.
It's clearly not completely monolithic if you can run two fairly central components without even the init daemon present.
rapidly becoming non-optional
Yes, in some distros. It's entirely up to the distro maintainers what options they want to support. That they choose to focus on supporting systemd is hardly systemd's fault.
was quickly shoved into every distro that matters.
Systemd was included in Fedora 15 which was released almost five years ago and we still have distros that are going to switch. This is one of the slowest tech migrations ever to take place in the GNU/Linux community.
Rooting/Hacking and other security issues. They don't want you to be able to downgrade to a "rootable" version, and pushing security updates to prevent this would be a nightmare if they had to support multiple previous versions.
Well, they could just use the exact same updating system that they have on OS X which supports branched updates. There's absolutely nothing unusual or particularly hard about supporting multiple versions of an operating system.
It's not just the package format. You can't even take a deb reliably between Debian and Ubuntu, or even between different releases of Ubuntu. There are different versions of libraries, sometimes with different soname. Making one package that runs everywhere is almost impossible unless you bundle pretty much every dependency.
Of course. It's not just plain text appended to a set of files so you would have to use journalctl to access them. Nothing wrong with that. Now this gives you a number of benefits. Since journald actually knows about the data that it stores it can make intelligent decisions. Everyone who has ever had to clean up a filled up/var/log partition knows how broken logrotate is. What if the journal could actually know about this and rotate based on size? It also makes it possible to actually search for things without having to take different date and log formats into account, and actually know that it came from the correct program. I know, crazy.
I'm missing something here. With all the flap about systemd, why the rush of all the distros to adopt it?
There has hardly been a "rush" to speak of. Fedora was first and switched in 2011, that's almost five years ago and we still have distros that haven't switched yet. This is one of the absolute slowest tech migration ever in the Linux community.
I'm on Mint, but even that is slated to go to systemd at the next major release. Binary logs, etc.? No thanks.
If you by "binary logs" mean regular text logs with a bit of metadata attached so that you can actually find stuff then yes, that's a good thing.
There are so many better terms. Computing Science and Datalogi are my favorites. CS is not about computers, it's unfortunate that people don't understand that.
Slashdot Mirror
Bugs were introduced (probably not on purpose) into GTK2 after GTK3 was released, and those bugs will never be fixed. For example I periodically get bug reports for one of my applications which I’ve traced down to GtkFileChooserButton and it’s a known issue noone will fix in GTK2.
Gtk2 is still maintained and as far as I know there are no immediate plans to stop that. We had a gtk2 release just last month which fixed eight bugs.
Huge parts of GTK2 have been deprecated, for example:
The horizontal/vertical Box layout scheme, which is how you were supposed to do all layouts in GTK2, and despite the deprecation warnings from the compiler there has been no alternative layout mechanism identified in the documentation.
The entire thread API, which is at the centre of any multi-threaded application. I don’t know if this was replaced with something else or dropped completely.
The GtkVBox/GtkHBox classes are deprecated but the documentation names several alternatives, the primary one being GtkGrid which combines the functionality of both classes.
I don't know what he means by the thread API. The GThread API is not going anywhere if that's what he mean.
The new library is clearly unfinished. For example the GtkAboutDialog is simply broken in the current version of GTK3.
Not sure what he means here. As far as I know it's used by several applications.
Serious bugs in GTK3 are ignored. For example I spent a day researching why they broke the scrollbars in GTK3, found that it was probably done accidentally (the new functionality doesn’t fit even their own designs), filed a bug, and five months later – still not so much as an acknowledgement that this is a problem.
I completely agree that this is a problem. The team developing and maintaining Gtk+ is understaffed and this is an unfortunate side affect.
GTK widgets don't have any style at all, it's all done via css themes. GTK does ship with the Adwaita theme by default, early versions of gtk3 did not do that and could look very badly if a theme was not installed.
Please correct me if I'm wrong but as far as I know gedit's GUI redesign did not remove any features. Some of the visual clutter was removed, like the toolbar buttons from where you could cut, copy and paste. There are of course other ways to access those features.
They don't use gconf anymore, they switched to dconf a couple of years ago. And a lot of settings that can't be accessed from the settings app can be accessed from the GNOME tweak tool, which is also a GUI.
CSD has led to many improvements. Just look at the gedit screenshot you linked to. Since we're able to reuse the title area for widgets we don't have to put a big toolbar under it. The editor actually has more space now compared to the old UI without loosing any features.
I'm a GNOME user and I want would certainly appreciate the new way that the settings looks. It looks like an improvement over the old icon grid where you had to go back and forth just to get to another settings pane.
You run out of capacity on the database server. You set up another one and now you have two. Problem solved. I see it all the time. They have lots of load balanced web servers handling all the front end traffic, but just one monolithic database server in the back that is holding everything back.
Well, being able to scale horizontally is still useful even if you're a small player. Just being able to fire up a second database host and automatically scale up is wonderful for the few times you're actually running out of capacity. Being able to scale up with little effort doesn't mean that you have to scale up big.
The Oklahoma Employment Security Commission clearly don't pay for an update themself. Windows Server 2003 has been end of life and unsupported for quite some time now.
All users have to do is upgrade to the latest version and they will continue to get patches. This will only affect users running old versions of IE on versions of Windows that can run a newer version.
They don't want to encourage anyone to use Vista anymore. It's a rather old OS that is running out of support next year so they do as little as possible and only support IE 9 on Vista until then.
How can you become someone like him? Just make things up and force distros to use it...
Wait a minute, that's not really what happened didn't it?
Journald does compression and the structure allows it to actually verify that the logs are sound. Remember that logs can be damaged for multiple reasons. Bugs are of course one reason but the more scary reason is tampering. Syslog has absolutely nothing that prevents tampering with logs. Everything that is submitted to syslog goes in, there is no verification that it's even the correct program. Play around with the logger command on a Linux box and you will be scared. Journald on the other hand actually verifies that the data that goes into the logs are from the correct sender and that once they have been entered you can verify that they have not been tampered with.
Something needs to respond to the syslog calls. I guess that could go into systemd init but I heard some people didn't like putting stuff into PID 1.
* Use tools such as Lets Encrypt on all websites (good idea in theory, in practice not feasible due to 3 month certs)
Take it as a good incentive to learn automation.
What does that even mean? When you enable syslog forwarding the journal will send it to syslog directly without going into the journal. You can even disable the journal log if you don't want it and only want to rely on syslog. So there is no binary log that can "crap out". It just sends it off to the syslog, just like sysvinit handled syslog.
That's because it's not related to init. Init is one subsystem. systemd, being a process manager, doesn't care if init is included or even when it is started. Once it's started, the communication between the parts are within the systemd communication channels (increasingly). This is what makes it monolithic. SMH
Please correct me if I'm wrong here but what process manager are you talking about? Pid 1 on Ubuntu 14.04 is upstart and it owns both of those two services. They are as far as I can see running completely independent.
The main arguments against systemd are that it's monolithic
Here is the output of ps -ef | grep systemd on a Ubuntu 14.04 desktop which uses upstart and not systemd as its init system:
root 387 1 0 2015 ? 00:00:00 /lib/systemd/systemd-udevd --daemon /lib/systemd/systemd-logind
root 701 1 0 2015 ? 00:00:00
It's clearly not completely monolithic if you can run two fairly central components without even the init daemon present.
rapidly becoming non-optional
Yes, in some distros. It's entirely up to the distro maintainers what options they want to support. That they choose to focus on supporting systemd is hardly systemd's fault.
was quickly shoved into every distro that matters.
Systemd was included in Fedora 15 which was released almost five years ago and we still have distros that are going to switch. This is one of the slowest tech migrations ever to take place in the GNU/Linux community.
Rooting/Hacking and other security issues. They don't want you to be able to downgrade to a "rootable" version, and pushing security updates to prevent this would be a nightmare if they had to support multiple previous versions.
Well, they could just use the exact same updating system that they have on OS X which supports branched updates. There's absolutely nothing unusual or particularly hard about supporting multiple versions of an operating system.
Greece tried that some time ago. It doesn't take long before the ATMs run out so we're basically screwed, cash or not.
It's not just the package format. You can't even take a deb reliably between Debian and Ubuntu, or even between different releases of Ubuntu. There are different versions of libraries, sometimes with different soname. Making one package that runs everywhere is almost impossible unless you bundle pretty much every dependency.
Someone did, the result is called dnf and has replaced yum in Fedora.
Of course. It's not just plain text appended to a set of files so you would have to use journalctl to access them. Nothing wrong with that. Now this gives you a number of benefits. Since journald actually knows about the data that it stores it can make intelligent decisions. Everyone who has ever had to clean up a filled up /var/log partition knows how broken logrotate is. What if the journal could actually know about this and rotate based on size? It also makes it possible to actually search for things without having to take different date and log formats into account, and actually know that it came from the correct program. I know, crazy.
I'm missing something here. With all the flap about systemd, why the rush of all the distros to adopt it?
There has hardly been a "rush" to speak of. Fedora was first and switched in 2011, that's almost five years ago and we still have distros that haven't switched yet. This is one of the absolute slowest tech migration ever in the Linux community.
I'm on Mint, but even that is slated to go to systemd at the next major release. Binary logs, etc.? No thanks.
If you by "binary logs" mean regular text logs with a bit of metadata attached so that you can actually find stuff then yes, that's a good thing.
There are so many better terms. Computing Science and Datalogi are my favorites. CS is not about computers, it's unfortunate that people don't understand that.