A PC Engines APU1C can "route" (NAT/gateway) around 6-700mbit/sec with pfSense on a 1GHz AMD A-series CPU with no hardware acceleration. That's nothing, hardware-wise. It has Realtek network cards which aren't great from a performance standpoint. I don't disagree that 10G+ service is going to take a fair bit of hardware compared to average home "router" hardware, but that's because those boxes are trash for the most part.

It's not always cost that limits bus widths. See PCI for example. They tried widening it (64 bit) and clocking it up (66, 133, and very rarely even beyond), but what won out is a much higher clocked serial interface (PCI Express).

Skew in a parallel interface is a bitch, plus the number of traces required on the board to support a wide bus. There's only so many connections you can practically run in to any given chip package without getting unmanageable.

ECC does not mitigate it, but it will detect the problem where non-ECC memory will happily keep on operating with the corrupted data.

For the standard car analogy, consider tire pressure monitoring systems. They won't stop you from getting a flat, but they'll let you know you have a slow leak where you might otherwise keep driving until it's bad enough that you notice otherwise. By that time the damage is done and you probably need a new tire.

Seriously, I'm pretty sure the first touch screen I ever used back in the early '90s used basically the same method. You didn't have to actually touch the screen, since it was a CRT and was usually curved where the sensor plane was flat.

SS7 dates to the '70s. Pretty much no communications protocols intended for general use were designed with even the thought of security at the time. The number of players in the game was small enough that any bad behavior could be rooted out fairly easily.

Look at email for the same basic problem, it was designed with the assumption that the parties involved could be trusted because on the networks it was designed for that was generally the case. Over time the trustworthiness of the network was degraded for reasons both good and bad, but the common protocols had already been established by then and it's a long road to change.

I won't argue that there probably has been some "influence" on decisions about adopting more secure replacements, but it's a bit tinfoil hattish to claim that the protocols themselves were intentionally made insecure when it's well documented that most protocols from that era just weren't designed to try to be secure in the first place.

Individual is the key word there. The BSA (and thus I agree by extension Microsoft) has a well documented track record of suing companies using pirated software. If you take them at their word that there were a large number of different devices activating those products from that IP address it seems reasonable that the same is exactly what's happening here. Individual pirates would be like the RIAA and MPAA going after actual people and families.

Or that IP is an exit point for Tor or a VPN or whatever and whoever's actually doing it is somewhere else, who can say.

Probably that leaving init scripts behind worked out for them. Their lack of presence in the datacenter doesn't really have anything to do with their init system but instead their attachment to proprietary hardware which offered little advantage over a generic PC either whitebox or from your preferred OEM running Linux or your BSD of choice. Likewise for OS X.

Because babies and bathwater and such.

A lot of people are convinced that systemd is the devil, so because humans are pretty stupid about this kind of thing they decide that if systemd is "them" then "us" must be shitty-ass init scripts.

Init scripts fucking suck no matter the application. Desktop, server, whatever. No dependencies, no standard format for easy maintenance, and a mess of either hardcoded paths or variables you may have to chase through multiple scripts to find. Anything that replaces them with a more sane system that realizes I have multiple cores and the web server couldn't care less whether OpenSSH is running is a good thing.

Well yeah, because the only place such discussion would likely be would be in a science book, and what's in a science book should be supported by evidence. The kind of "questioning global warming" that people like you mean is not supported by evidence, it's distorting evidence, and does not belong in a science book.

As Colbert put best, "reality has a well-known liberal bias". It comes from being willing to actually ask questions and observe the world to find our answers, rather than an unwavering loyalty to an ideology. In this case these fucknuts are taking their religious beliefs, based on nothing, and prioritizing them over actual science. That's not political in any way, that's just fucking idiots. Unfortunately for those who are politically conservative but aren't insane the "conservative" party has spent 20 years courting the religious morons in every possible way and happily set themselves up for this kind of shit.

There were 13 seats up for grabs in North Carolina in 2012. In the real election, Republicans won nine of these with Democrats getting the remaining four. In Duke's simulations using randomly generated districts the majority of the time more seats went to Democrats than Republicans, averaging apparently in the 7.x range for Democrats and 5.x for Republicans. Almost never did it swing so far in favor of Republicans as to even approach the real world outcome.

Since the real world outcome is unlikely in a map generated by an unbiased algorithm it supports the claim that the districts were drawn in a biased fashion.

The BMW E46 (3 series between 1999 and 2005) and other BMWs from that era all use an in-vehicle network called "I-Bus" which operates things like the windows, the sound system, the lights, and more. Most non-critical vehicle functions are exposed there and are fairly well documented by the community. You only need an inexpensive adapter that looks like a serial port as far as the computer's concerned to access it.

IIRC the first generation or two of Mini as well as a few Land Rovers of the time that used BMW engines also have I-Bus.

Newer models have an optical system called MOST running the infotainment system, I'm not sure where the windows and lights are connected in these days.

While being kept on life support by those who still care is definitely alive, I wouldn't say well for any of those. They're all in a long tail phase of life where those who still use them won't change unless forced, but basically nothing new is being done with them so the user and support bases will slowly dwindle until it truly is dead.

Let's take a look at the full quote again...

To me, that's calling the subset of the community who were shitty about it immature twats, not taking sides in the debate at all. Anyone can agree that there were plenty of people on both sides of the systemd issue who were most certainly deserving of the title "immature twat", so I don't have any problem with this statement.

I think you then sort of pot-kettle-black yourself with this:

As if the pro-systemd side was the only one with activist fans who don't understand the actual situation. Many of the criticisms have merit, but others do not and yet are continually parroted. The binary log for example, where the anti-systemd folks constantly complain that it's not ACID and that it'll be easily corrupted in a crash but never quite manage to explain how the plain text log doesn't have the same problem.

Personally I dislike systemd's breadth due to its impact on portability for those apps that would have to interact with it in a systemd environment, but I want an init system that is aware of dependencies so my boot process doesn't have to wait on something slow. As a side benefit I can have it automatically restart dependent services when something important needs to be restarted, like networking. Basically I'm not a fan of systemd, but it seems to be the only realistic chance to get what I want in an init system any time soon so given the choice between it and the status quo I say all hail our new integrated overlords.

It's not the script itself, it's the fact that init scripts are run sequentially. I have eight cores, there's no reason for seven of them to be sitting idle while one of the services being started shoves its thumb up its ass. Anything else that doesn't care whether the stuck service lives or dies should be able to start on its own.

Traditional init scripts can not do that.

Obviously that doesn't matter to the person who admins a cloud style infrastructure where each host (virtual or physical) has only one role and thus dependencies are basically sequential, but to anyone on an end-user machine or anyone operating a multi-role server it's very useful.

tl;dr: systemd may not be the right answer, but bash scripts are not without some major flaws which will require reducing or eliminating their influence on the boot process to resolve.

If the task is complex, you can do it over dozens of times or you can do it once well. No one's hiding anything, it's all open source. It's just that with systemd or a similar system any tangled messes that may have to remain aren't directly exposed to people who just want to change a command line flag or run their homebrewed app as a service.

When you use a lot of software from outside the normal system packages you tend to notice that a lot of init scripts end up looking very much like a lot of others. There seem to be a few basic templates that people started modifying and ended up forked a bunch of different ways, all to accomplish the same basic things.

If you implement all of those common tasks in one standard tool or package of tools, suddenly all of those different and potentially buggy in their own way reinventions of the wheel become one easily updated thing. You have to get that right, but with large distros going this way any major issues are likely to show themselves quickly. As long as they can be fixed in a timely fashion it's not a huge problem.

For the record I take no position on systemd. I believe that a parallel, dependency-based replacement for init is far overdue so I like the concept as far as that goes but I don't know enough about the implementation to judge systemd specifically.