No. The person you replied to is correct. Telemetry is not on at all by default in release versions of Firefox. However it is on by default on pre-release versions (this is when it will tell you that they are collecting some data). For more info see this article: https://wiki.mozilla.org/Telem...
And on what grounds are they going to force him to get help? He expressed a desire to make a bomb and detonate it, but anyone could express that desire and not actually act on it. That seems like pretty poor grounds to force someone to get help.
Could they have done it when he attempted to buy the goods to make the bomb? Possibly. But I still think those are pretty shaky grounds.
What if they swapped out the potentiality dangerous elements he buys and then waiting until he actually attempts to go through with what he originally proposed? In that case no one would get hurt because the materials he used are rendered inoperative and now they have an actual case to get him help.
I would also like to point out that the OP never actually said anything about getting him help. Only that the FBI should have stopped the attack (Which they did, at the very least, by rendering the materials useless).
I didn't make a distinction between learning and learning effectively in my post, and I see I should have. It's very easy to learn things, one way or another. However to be able to learn things quickly and effectively requires skill that has to develop. For some people, like me, High School was too easy. I never learned how to learn properly there. College was a different story though. I had to actually study and do research.
Now, that doesn't mean that I couldn't have done so on my own. However, in certainly accelerated the process. And not only did I learn how to learn effectively, I also learned a basic skillset for my career. What it really boils down to is this: Would you learn material more effectively on your own or by being guided by a room full of experts in the field you want to get into?
College is not needed to learn how to learn things.
I think it's important to point out that while you may not have needed college to give you a good learning methodology, the parent poster and likely many other people do. And for those who don't need college to do so, they may learn how to learn faster in college than they would have without college.
If they actually forked the kernel I'm pretty sure it would be in theirrepository and not one that's 11 days old.
News like that just feels like an April fools joke to me and I would assume it would to others. I mean, the systemd developers don't operate like that at all. That people would think it to be true at all shows how strange of a perception there is around the systemd project (take that as you want, one way or another people think the systemd devs would be crazy enough to do a full out fork of the kernel--does that mean people are deluded about systemd's goals or that systemd has put off indications that they would do such a thing).
My point is still valid no matter the victim or the culprit. I was merely using the previous scenario as an example. It's just as true if the roles were reversed or in any other number of scenarios.
For example, let's say that a parent has told their child that they're not allowed to eat any candy until after dinner because it would spoil their appetite. The parent then proceeds to pour a bowl of candy onto a nearby table and then walks out of the room. And of course, the child takes and eats some candy once the parent leaves. Now, is it the child's fault for taking the candy? Absolutely. However, the parent should have known better than to leave such a temptation for the child in such an accessible place and then walk away. The parent should also carry some blame because it was a foolish thing to do.
My prior example was not meant as a commentary on telling women (or really anyone) what they can and cannot wear. Rather, it was meant to show that in certain situations it is unwise (and I posit even immoral) to do things that would be an obvious temptation to another party to do wrong. Not that that would make the culprit any less blame worthy.
it is possible for a butt naked woman to walk up to a sex starved man, and the man to know he has no right to touch her without her consent, and to simply not touch her. if he chooses to touch her without her agreeing then he, and he alone, has committed a crime. she has committed no crime. none
you are responsible for your choices and what you do. no matter the temptation. no matter the context
the actions that come out of you is your fault only. 100%
The problem I have with such a view is that it completely absolves the "victim" of any blame whatsoever. Now, that doesn't mean that in your scenario that the person who touches the woman is not at fault. He is. Absolutely, he is. But is it not also morally wrong to put someone into a situation where you know they're going to have a hard time doing the correct/legal thing?
Of course, that requires that the "victim" be fully aware of the potential dangers of what they're doing, and in the larger context of this conversation that's just not the case. However, my point still stands. Just because one is a victim does not mean that one can be wholly absolved of any wrongdoing. Naturally, the culprit holds full blame for their actions, however in the larger context the victim can also hold at least some part of the blame for putting the culprit in such a situation.
Yeah. I have to agree with this to a degree. There are a great number of childish and petty people in BOTH camps. I've seen good anti-systemd posts get modded troll and I've seen good pro-systemd posts get modded troll. To attack the project community (or anti-project) community based on the toxic fringes of each seems counterintuitive.
(Disclaimer: I'm from the pro-systemd camp, and while I've tried to keep my posts as nice as possible I'm sure I've slipped from time to time. For that, I'm sorry.)
It's also married to the logging daemon. So add in the complexity of that, please. Also, you'll have to throw in d-bus and udev, since it ate those too and those are core services for it as well.
You're right, it requires journald, dbus, and udev (if it's not running in a container). And if you want to do process monitoring or device monitoring during boot those (dbus and udev, not journald) are a requirement anyway. Which is why Upstart pulled them in. They do add some complexity, sure, but they're fairly well tested components and again, not very large by comparison. And in the end, you end up with a system that can give you more information about a failed boot, or even attempt to solve problems with failed startup services since it can get more detailed information about what went wrong.
Having Unix Domain sockets is minimally troubling, because it's minimally complicated. Adding IP networking is more troubling, because it's more complicated. It provides not just attack surface, but also more opportunities to make mistakes which could result in PID 1 cratering. . . . Right now I can mix and match syslogs, init daemons, whatever. systemd wants to take that away from me.
As far as I know PID1 doesn't do IP networking. That's another (optional) component, so the attack surface should be the same as any other IP networking daemon. Unless I'm missing something?
I see a lot of people saying that it's possible for things to go catastrophically wrong during a systemd init, but so far there it really hasn't happened too often. It's usually something like one of the core components is missing or it's related to one of the earlier versions of systemd. And it was certainly possible for things to go terribly awry when using SysV init, as I personally encountered that once. I don't know, I can see why more code could mean more potential breakage, but that just doesn't seem to be the case.
And you can still mix and match most things, including logging systems (you just have to have at least journald).
Some things about a system need to be complicated.
PID 1 is not one of those things, nor does it need to be married to a specific log daemon.
The core part of systemd isn't that complicated. And on the user side it's significantly more simple. You can't mess up your boot process by mistyping something in one of the boot scripts (one of the problems with using sh scripts for boot). I'm not sure exactly why they tied it directly to journald other than journald having a better interface (and being available earlier in boot than other logging daemons), plus it's still possible to use another logging daemon if you want. Albeit it will run alongside journald.
Ergo, parts of systemd need to be complicated.
Which parts, and why? So far, no one has given a satisfactory argument as to why the complexity now encompassed by systemd needs to be part of a single project, let alone one controlled by someone who has shown themself to be not particularly competent.
It's not like systemd is some huge single project. It's all in one repository, but it's actually made up of a bunch of smaller, modular projects that are all under the "systemd" umbrella. And I really don't think it's relevant to bring the maintainer of the project into this. The community at large has swayed the direction systemd has taken quite a bit (as evidenced by the huge amount of feedback in the mailing lists) and apart from some core standpoints the maintainer is flexible.
The "simple solution" argument really loses steam when you think about the kernel. It's not exactly a simple piece of code. It's complicated. With many different parts that do many different things. Is the kernel a problem?
Yes. Yes, the kernel's all-encompassing complexity is a problem. It causes serious problems all the time. Like, for example, just trying to build a kernel. When was the last time you built a kernel of any complexity from the source tarball and without starting with an already-proven-working-on-your-hardware.config file? Good fucking luck, especially if you were planning to have many modules around "just in case". I, for one, do not like to be caught flat-footed if I have to boot my backup on another system. And perhaps you missed the hard lockup bug that's been going around since approximately forever, which we've been discussing here on Slashdot with each new kernel point release? Is it fixed, the extent to which it isn't fixed? Hello? Is this thing on? Which rock have you been under, anyway?
However, the problems caused by breaking up the kernel were perceived as being more serious than the problems caused by not breaking up the kernel. Is that true? It's hard to say. Minix is only now becoming vaguely usable as a general-purpose OS for normal users, and the Hurd is still more like the Butt... of every joke about microkernels. Granted, if they'd received more support then perhaps they'd be dramatically further along, but their architecture is part of the reason they haven't had more support. It's sort of inseparable from them. If Linus had chosen to write a microkernel-based system, it's conceivable that far fewer of the people who made Linux the success that it is today would have gotten involved. Likewise, there's no guarantee that anyone who helped make Linux great would have worked on the Hurd or on Minix — perhaps most of them (those attracted to Linux by the GPL aside) would have gone into one of the BSD camps.
Systemd is broken up into modular parts, so it's actually more like Minix than Linux in this regard. Obviously the PID1 part isn't modular, but it's also not terribly large or complex in comparison to the project as a whole.
It's complicated because it needs to be so, just as systemd must be.
Some things about a system need to be complicated. A lot of the problems that components of systemd solve are non-trivial problems. Ergo, parts of systemd need to be complicated.
The "simple solution" argument really loses steam when you think about the kernel. It's not exactly a simple piece of code. It's complicated. With many different parts that do many different things. Is the kernel a problem? No. It's complicated because it needs to be so, just as systemd must be.
So the thing that put you over the top with systemd is that the documentation for another init system command differs from the command provided by systemd?
Just to be clear about this, the "shutdown" command as provided by systemd is basically a symbolic link to the "systemctl" command. It's provided as a convenience for those who are more used to the traditional SysV and Upstart way of doing things, and it certainly doesn't guarantee 100% compatibility as systemd has a very different way of doing things.
To put this into a car analogy this is like complaining about not having a cassette player in a modern car. Sure, it may be inconvenient for those who have a ton of cassettes, but there's a different way to play music in cars now. Actually, it's even better than that. It's more like the radio does have a cassette player in addition to the typical CD player, it just doesn't automatically switch sides for when playing anymore.
While many people seem to say that, I don't believe that's the actual claim. I think the claim is that it's easier to find bugs in free/open source software because the code can be read by everyone. That is, it's more likely that if there is a bug it will be found and fixed. While that may imply, to a certain degree, that bugs can go undetected for longer in closed source software it certainly doesn't state it outright. And in large code bases like X.org it's hard to imagine that old pieces of code that haven't been looked at in a long time wouldn't have some rather large vulnerabilities. At least now some of them have been found and patched.
Plus I think it's also important to think about it from this angle: Do you have any examples of closed-source software that has been in use since 1987 that hasn't had any bugs discovered recently?
Probably sometime after electrolysis[1] (e10s) lands. That's probably going to take a while because there's a lot to do between now and when it will be deemed release ready (add-on compatibility, switching some internal components over to e10s friendly versions, memory checks, and various other odds and ends).
If it's flash or other plugins that were causing the CPU usage then recent versions of Firefox already have that covered. Plugins can be set to click to activate (so it will only run on sites you enable it for) and if one does run out of control then killing the "plugin-container" child process will kill all of the plugins (which can then be reloaded by reloading the tab). As for Javascript running out of control for a particular tab, there's no current solution.
I think the OP was talking about a full replace rebuild in which case a write-intent bitmap isn't going to make a difference.
(In case anyone doesn't know and is too lazy to read the linked article above, a write-intent bitmap is for when you pull/reseat a drive or when the computer is improperly shutdown. It basically just copies the changes instead of having to completely rebuild. tl;dr: It's a journal at the RAID level)
And to answer any systemd apologist who will mention that it can configured to log to syslog, that won't help if there is a problem in the vast complexity of systemd that prevents it from ever getting started to that point.
And if there is a problem in the vast complexity of syslog then you won't have any help there either. Of course that's ridiculous because syslog implementations are developed with care to make sure that a failure like that doesn't happen. The same can be said for journald. The developers are going to pay close attention to something as critical as the logging mechanism. Of course, there are always bugs but showstoppers should be VERY rare (and anecdotally they are, I have yet to encounter even a slight hiccup with journald).
I also fail to see why storing information in a binary format somehow makes it "poor engineering". It's not like the data is inaccessible, it may not be directly human-readable so it requires another tool to read it, but then even plain text files will need some kind of external program to display their contents (grep, emacs, vim, more, cat, etc.).
I think you missed the part where it said that was an OPTIONAL dependency. It also explains why that dependency is needed (that is, what would be affected if that kernel module isn't loaded, in this case it helps prevent a boot failure).
To be fair, this thread is referencing both Arch Linux and Gentoo. In both cases those distributions aim to be as "bleeding edge" as possible. Plus Arch Linux puts things that may break during upgrade in the [testing] repo for a while so people can test it if they want to (baked into the distro) while leaving the majority out of it. Gentoo may have a similar system, I don't have enough experience with it to say either way.
Saying that it's irresponsible to make the most recent version of software available to users (especially in this case where the users are assumed to be power-users at least) is kind of ridiculous given the nature and goals of Arch Linux and Gentoo.
That depends. The kernel hasn't been moved into Arch's [core] repository yet, but it is in the [testing] one (it was there first, but just barely, according to the times it was just two hours ahead of Gentoo[1] [2]). Not that it matters which was first anyway, they're both rolling release and will have it much earlier than a distro using a standard release model.
[1] ArchLinux testing/linux package push date at 2014-08-04 06:24:21 (GMT) Source
[2] Gentoo sys-kernel/linux-headers changelog change date at Mon Aug 4 09:39:49 2014 UTC Source
KDE gives us a desktop! Yes! But it also gives us nepomuk, baloo, akonadi, virtuoso... KDE has so much useless bloat on it.
Baloo has replaced both nepomuk and virtuoso and is far more slim (both code-wise, memory-wise, and CPU usage-wise). And really it's one of the nicest things to have around if you just want to find something fast. Calling something like that (which is providing a feature which every other major desktop has) bloat seems like a bit of a stretch.
Akonadi isn't really bloat either. It's required to have a truly semantic desktop. Now, that may not be for everyone, but it helps provide a smoother experience for PIM stuffs. Albeit, it has had a fairly rough time. The bugs with Akonadi can be particularly annoying to end-users. (Anecdote warning!) I haven't had any problems with Akonadi in a long time. Of course, I did also switch the database engine to PostgreSQL, I have no idea if that made any kind of difference.
I've also heard bloat complaints about Phonon, and I agree with them to a degree. Phonon seems like it's overkill since, for the most part, most audio is already sent through multiple abstraction layers before it's consumed by an application. However, during the time Phonon was created there was really no clear way to know which abstractions would win out (and even now gstreamer and vlc both provide about the same feature set) so having a way to build an application without having to worry about that kind of detail made sense (and still does make some sense).
Slashdot Mirror
No. The person you replied to is correct. Telemetry is not on at all by default in release versions of Firefox. However it is on by default on pre-release versions (this is when it will tell you that they are collecting some data). For more info see this article: https://wiki.mozilla.org/Telem...
This is false. Release versions of Firefox do not enable telemetry. See https://wiki.mozilla.org/Telem... for more info.
Posting to undo accidental mod.
And on what grounds are they going to force him to get help? He expressed a desire to make a bomb and detonate it, but anyone could express that desire and not actually act on it. That seems like pretty poor grounds to force someone to get help.
Could they have done it when he attempted to buy the goods to make the bomb? Possibly. But I still think those are pretty shaky grounds.
What if they swapped out the potentiality dangerous elements he buys and then waiting until he actually attempts to go through with what he originally proposed? In that case no one would get hurt because the materials he used are rendered inoperative and now they have an actual case to get him help.
I would also like to point out that the OP never actually said anything about getting him help. Only that the FBI should have stopped the attack (Which they did, at the very least, by rendering the materials useless).
Er, wouldn't it be wiFi then?
I didn't make a distinction between learning and learning effectively in my post, and I see I should have. It's very easy to learn things, one way or another. However to be able to learn things quickly and effectively requires skill that has to develop. For some people, like me, High School was too easy. I never learned how to learn properly there. College was a different story though. I had to actually study and do research.
Now, that doesn't mean that I couldn't have done so on my own. However, in certainly accelerated the process. And not only did I learn how to learn effectively, I also learned a basic skillset for my career. What it really boils down to is this: Would you learn material more effectively on your own or by being guided by a room full of experts in the field you want to get into?
College is not needed to learn how to learn things.
I think it's important to point out that while you may not have needed college to give you a good learning methodology, the parent poster and likely many other people do. And for those who don't need college to do so, they may learn how to learn faster in college than they would have without college.
If they actually forked the kernel I'm pretty sure it would be in their repository and not one that's 11 days old.
News like that just feels like an April fools joke to me and I would assume it would to others. I mean, the systemd developers don't operate like that at all. That people would think it to be true at all shows how strange of a perception there is around the systemd project (take that as you want, one way or another people think the systemd devs would be crazy enough to do a full out fork of the kernel--does that mean people are deluded about systemd's goals or that systemd has put off indications that they would do such a thing).
My point is still valid no matter the victim or the culprit. I was merely using the previous scenario as an example. It's just as true if the roles were reversed or in any other number of scenarios.
For example, let's say that a parent has told their child that they're not allowed to eat any candy until after dinner because it would spoil their appetite. The parent then proceeds to pour a bowl of candy onto a nearby table and then walks out of the room. And of course, the child takes and eats some candy once the parent leaves. Now, is it the child's fault for taking the candy? Absolutely. However, the parent should have known better than to leave such a temptation for the child in such an accessible place and then walk away. The parent should also carry some blame because it was a foolish thing to do.
My prior example was not meant as a commentary on telling women (or really anyone) what they can and cannot wear. Rather, it was meant to show that in certain situations it is unwise (and I posit even immoral) to do things that would be an obvious temptation to another party to do wrong. Not that that would make the culprit any less blame worthy.
it is possible for a butt naked woman to walk up to a sex starved man, and the man to know he has no right to touch her without her consent, and to simply not touch her. if he chooses to touch her without her agreeing then he, and he alone, has committed a crime. she has committed no crime. none
you are responsible for your choices and what you do. no matter the temptation. no matter the context
the actions that come out of you is your fault only. 100%
The problem I have with such a view is that it completely absolves the "victim" of any blame whatsoever. Now, that doesn't mean that in your scenario that the person who touches the woman is not at fault. He is. Absolutely, he is. But is it not also morally wrong to put someone into a situation where you know they're going to have a hard time doing the correct/legal thing?
Of course, that requires that the "victim" be fully aware of the potential dangers of what they're doing, and in the larger context of this conversation that's just not the case. However, my point still stands. Just because one is a victim does not mean that one can be wholly absolved of any wrongdoing. Naturally, the culprit holds full blame for their actions, however in the larger context the victim can also hold at least some part of the blame for putting the culprit in such a situation.
Yeah. I have to agree with this to a degree. There are a great number of childish and petty people in BOTH camps. I've seen good anti-systemd posts get modded troll and I've seen good pro-systemd posts get modded troll. To attack the project community (or anti-project) community based on the toxic fringes of each seems counterintuitive.
(Disclaimer: I'm from the pro-systemd camp, and while I've tried to keep my posts as nice as possible I'm sure I've slipped from time to time. For that, I'm sorry.)
Whoosh?
It's also married to the logging daemon. So add in the complexity of that, please. Also, you'll have to throw in d-bus and udev, since it ate those too and those are core services for it as well.
You're right, it requires journald, dbus, and udev (if it's not running in a container). And if you want to do process monitoring or device monitoring during boot those (dbus and udev, not journald) are a requirement anyway. Which is why Upstart pulled them in. They do add some complexity, sure, but they're fairly well tested components and again, not very large by comparison. And in the end, you end up with a system that can give you more information about a failed boot, or even attempt to solve problems with failed startup services since it can get more detailed information about what went wrong.
Having Unix Domain sockets is minimally troubling, because it's minimally complicated. Adding IP networking is more troubling, because it's more complicated. It provides not just attack surface, but also more opportunities to make mistakes which could result in PID 1 cratering. . . . Right now I can mix and match syslogs, init daemons, whatever. systemd wants to take that away from me.
As far as I know PID1 doesn't do IP networking. That's another (optional) component, so the attack surface should be the same as any other IP networking daemon. Unless I'm missing something?
I see a lot of people saying that it's possible for things to go catastrophically wrong during a systemd init, but so far there it really hasn't happened too often. It's usually something like one of the core components is missing or it's related to one of the earlier versions of systemd. And it was certainly possible for things to go terribly awry when using SysV init, as I personally encountered that once. I don't know, I can see why more code could mean more potential breakage, but that just doesn't seem to be the case.
And you can still mix and match most things, including logging systems (you just have to have at least journald).
Some things about a system need to be complicated.
PID 1 is not one of those things, nor does it need to be married to a specific log daemon.
The core part of systemd isn't that complicated. And on the user side it's significantly more simple. You can't mess up your boot process by mistyping something in one of the boot scripts (one of the problems with using sh scripts for boot). I'm not sure exactly why they tied it directly to journald other than journald having a better interface (and being available earlier in boot than other logging daemons), plus it's still possible to use another logging daemon if you want. Albeit it will run alongside journald.
Ergo, parts of systemd need to be complicated.
Which parts, and why? So far, no one has given a satisfactory argument as to why the complexity now encompassed by systemd needs to be part of a single project, let alone one controlled by someone who has shown themself to be not particularly competent.
It's not like systemd is some huge single project. It's all in one repository, but it's actually made up of a bunch of smaller, modular projects that are all under the "systemd" umbrella. And I really don't think it's relevant to bring the maintainer of the project into this. The community at large has swayed the direction systemd has taken quite a bit (as evidenced by the huge amount of feedback in the mailing lists) and apart from some core standpoints the maintainer is flexible.
The "simple solution" argument really loses steam when you think about the kernel. It's not exactly a simple piece of code. It's complicated. With many different parts that do many different things. Is the kernel a problem?
Yes. Yes, the kernel's all-encompassing complexity is a problem. It causes serious problems all the time. Like, for example, just trying to build a kernel. When was the last time you built a kernel of any complexity from the source tarball and without starting with an already-proven-working-on-your-hardware .config file? Good fucking luck, especially if you were planning to have many modules around "just in case". I, for one, do not like to be caught flat-footed if I have to boot my backup on another system. And perhaps you missed the hard lockup bug that's been going around since approximately forever, which we've been discussing here on Slashdot with each new kernel point release? Is it fixed, the extent to which it isn't fixed? Hello? Is this thing on? Which rock have you been under, anyway?
However, the problems caused by breaking up the kernel were perceived as being more serious than the problems caused by not breaking up the kernel. Is that true? It's hard to say. Minix is only now becoming vaguely usable as a general-purpose OS for normal users, and the Hurd is still more like the Butt... of every joke about microkernels. Granted, if they'd received more support then perhaps they'd be dramatically further along, but their architecture is part of the reason they haven't had more support. It's sort of inseparable from them. If Linus had chosen to write a microkernel-based system, it's conceivable that far fewer of the people who made Linux the success that it is today would have gotten involved. Likewise, there's no guarantee that anyone who helped make Linux great would have worked on the Hurd or on Minix — perhaps most of them (those attracted to Linux by the GPL aside) would have gone into one of the BSD camps.
Systemd is broken up into modular parts, so it's actually more like Minix than Linux in this regard. Obviously the PID1 part isn't modular, but it's also not terribly large or complex in comparison to the project as a whole.
It's complicated because it needs to be so, just as systemd must be.
No. PID 1 ought to be as simple as poss
Some things about a system need to be complicated. A lot of the problems that components of systemd solve are non-trivial problems. Ergo, parts of systemd need to be complicated.
The "simple solution" argument really loses steam when you think about the kernel. It's not exactly a simple piece of code. It's complicated. With many different parts that do many different things. Is the kernel a problem? No. It's complicated because it needs to be so, just as systemd must be.
So the thing that put you over the top with systemd is that the documentation for another init system command differs from the command provided by systemd?
Just to be clear about this, the "shutdown" command as provided by systemd is basically a symbolic link to the "systemctl" command. It's provided as a convenience for those who are more used to the traditional SysV and Upstart way of doing things, and it certainly doesn't guarantee 100% compatibility as systemd has a very different way of doing things.
To put this into a car analogy this is like complaining about not having a cassette player in a modern car. Sure, it may be inconvenient for those who have a ton of cassettes, but there's a different way to play music in cars now. Actually, it's even better than that. It's more like the radio does have a cassette player in addition to the typical CD player, it just doesn't automatically switch sides for when playing anymore.
While many people seem to say that, I don't believe that's the actual claim. I think the claim is that it's easier to find bugs in free/open source software because the code can be read by everyone. That is, it's more likely that if there is a bug it will be found and fixed. While that may imply, to a certain degree, that bugs can go undetected for longer in closed source software it certainly doesn't state it outright. And in large code bases like X.org it's hard to imagine that old pieces of code that haven't been looked at in a long time wouldn't have some rather large vulnerabilities. At least now some of them have been found and patched.
Plus I think it's also important to think about it from this angle: Do you have any examples of closed-source software that has been in use since 1987 that hasn't had any bugs discovered recently?
Probably sometime after electrolysis[1] (e10s) lands. That's probably going to take a while because there's a lot to do between now and when it will be deemed release ready (add-on compatibility, switching some internal components over to e10s friendly versions, memory checks, and various other odds and ends).
If it's flash or other plugins that were causing the CPU usage then recent versions of Firefox already have that covered. Plugins can be set to click to activate (so it will only run on sites you enable it for) and if one does run out of control then killing the "plugin-container" child process will kill all of the plugins (which can then be reloaded by reloading the tab). As for Javascript running out of control for a particular tab, there's no current solution.
[1] https://wiki.mozilla.org/Elect...
I think the OP was talking about a full replace rebuild in which case a write-intent bitmap isn't going to make a difference.
(In case anyone doesn't know and is too lazy to read the linked article above, a write-intent bitmap is for when you pull/reseat a drive or when the computer is improperly shutdown. It basically just copies the changes instead of having to completely rebuild. tl;dr: It's a journal at the RAID level)
And to answer any systemd apologist who will mention that it can configured to log to syslog, that won't help if there is a problem in the vast complexity of systemd that prevents it from ever getting started to that point.
And if there is a problem in the vast complexity of syslog then you won't have any help there either. Of course that's ridiculous because syslog implementations are developed with care to make sure that a failure like that doesn't happen. The same can be said for journald. The developers are going to pay close attention to something as critical as the logging mechanism. Of course, there are always bugs but showstoppers should be VERY rare (and anecdotally they are, I have yet to encounter even a slight hiccup with journald).
I also fail to see why storing information in a binary format somehow makes it "poor engineering". It's not like the data is inaccessible, it may not be directly human-readable so it requires another tool to read it, but then even plain text files will need some kind of external program to display their contents (grep, emacs, vim, more, cat, etc.).
I think you missed the part where it said that was an OPTIONAL dependency. It also explains why that dependency is needed (that is, what would be affected if that kernel module isn't loaded, in this case it helps prevent a boot failure).
To be fair, this thread is referencing both Arch Linux and Gentoo. In both cases those distributions aim to be as "bleeding edge" as possible. Plus Arch Linux puts things that may break during upgrade in the [testing] repo for a while so people can test it if they want to (baked into the distro) while leaving the majority out of it. Gentoo may have a similar system, I don't have enough experience with it to say either way.
Saying that it's irresponsible to make the most recent version of software available to users (especially in this case where the users are assumed to be power-users at least) is kind of ridiculous given the nature and goals of Arch Linux and Gentoo.
That depends. The kernel hasn't been moved into Arch's [core] repository yet, but it is in the [testing] one (it was there first, but just barely, according to the times it was just two hours ahead of Gentoo[1] [2]). Not that it matters which was first anyway, they're both rolling release and will have it much earlier than a distro using a standard release model.
[1] ArchLinux testing/linux package push date at 2014-08-04 06:24:21 (GMT) Source
[2] Gentoo sys-kernel/linux-headers changelog change date at Mon Aug 4 09:39:49 2014 UTC Source
KDE gives us a desktop! Yes! But it also gives us nepomuk, baloo, akonadi, virtuoso... KDE has so much useless bloat on it.
Baloo has replaced both nepomuk and virtuoso and is far more slim (both code-wise, memory-wise, and CPU usage-wise). And really it's one of the nicest things to have around if you just want to find something fast. Calling something like that (which is providing a feature which every other major desktop has) bloat seems like a bit of a stretch.
Akonadi isn't really bloat either. It's required to have a truly semantic desktop. Now, that may not be for everyone, but it helps provide a smoother experience for PIM stuffs. Albeit, it has had a fairly rough time. The bugs with Akonadi can be particularly annoying to end-users. (Anecdote warning!) I haven't had any problems with Akonadi in a long time. Of course, I did also switch the database engine to PostgreSQL, I have no idea if that made any kind of difference.
I've also heard bloat complaints about Phonon, and I agree with them to a degree. Phonon seems like it's overkill since, for the most part, most audio is already sent through multiple abstraction layers before it's consumed by an application. However, during the time Phonon was created there was really no clear way to know which abstractions would win out (and even now gstreamer and vlc both provide about the same feature set) so having a way to build an application without having to worry about that kind of detail made sense (and still does make some sense).