Whoops, I was wrong - it's nearly 2 kilograms per person here, not 1. But you've still got us beat
I just think it's really weird how Americans see themselves as a major-fireworks nation when they set off so few.
Oh come on, what's New Years without an ER visit?
In case you're curious, here's what New Years looks like here. It goes on at that intensity for at least half an hour, half intensity for maybe an additional hour or so, quarter intensity for another hour, etc. All this comes after the "brennur", which is about a dozen house-sized bonfires scattered all over town.
Basically, if one can make it burn or explode and there's nobody who objects, we'll set it on fire. Often while drinking heavily
New York City for example usually sets off 20-25 tonnes of fireworks on the 4th of July. Meanwhile, little Reykjavík sets off about 300 tonnes on New Years' Eve. Americans average shooting off about 200 grams of Fireworks each over the course of the entire year, combining fireworks shows, personal usage, etc. Icelanders average about a kilogram per person just on New Years'.
And I know it's not just Iceland. I had a friend from Peru who moved to America and was terribly disappointed by what passed for a fireworks display there versus in her home country. Seriously, aren't you guys supposed to be the ones who enjoy blowing everything up?
(Note: not meant as an insult
For what I want it's fine. I have an emergency smart phone that I travel with (two SIM slots - 1 US, one international). I don't use cell data, only WiFi, and they've not nickel and dimed me at all. I buy $10 cards at the grocery store and refill every 3 months.
Sure, no problem. If you dislike systemd that much, it certainly makes sense to move to a different software platform.
I don't particularly dislike systemd per se. I do observe the controversy around it, and the image of it and its project, painted by its opponents (some of whom have enough creds that it's unlikely that they're talking through their hats), indicates that the claimed issues are likely to be real problems, and this may be a tipping point for Linux adoption and user choice among distributions or OSes.
Your Snowden argument isn't particularly applicable in this instance, as you have access to the full source code for systemd. If you're not comfortable looking through C code, then any init system would be a problem for you.
I did my first Linux drivers (a PROM burner and a Selectric-with-selonoids printer) on my personal Altos ACS 68000 running System III, wrote a driver for a block-structured tape drive for AUX - working from my own decompilation of their SCSI disk driver (since the sources weren't available to me initially), ported and augmented a mainframe RAID controller from SvR3 to SvR4, and so on, for nearly three decades, through hacking DeviceTree on my current project. I don't think C has many problems left for me, nor does moving to yet another UNIX environment - especially to one that is still organized in the old, familiar, fashion. B-)
As for trying to learn how systemd works, that's not the proper question. Instead, I ask what is so great about it that I should spend the time to do so, distracting me from my other work, and how doing this would meet my goals (especially the undertand-the-security-issues goal), as compared to moving to a well-supported, time-proven, high-reliability, security-conscious alternative (which is also under a license that is less of a sell to the PHBs when building it into a shippable product.)
Snowden's revealations show that the NSA, and others like them are adept, at taking advantage of problems in obscure corners of systems and using that obscurity to avoid detection. The defence against this is simplicity and clarity, avoiding the complexity that creates subtle bugs and hides them by burying them in distractions. Bigger haystacks hide more needles.
The configuration for systemd isn't buried. It's there for all to see and change, in plain text. Logging in binary form is _optional_. You can choose to direct logged messages to syslog, or use both syslog and binary, to have the "best of both worlds", albeit with the best of disk usage.
Unfortunately, I don't get to make that choice myself. It's made by the distribution maintainers. My choice is to accept it, open the can of worms and redo the work of entire teams (and hope their software updates don't break things faster than I fix them), or pick another distribution or OS.
Again, why should I put myself on such a treadmill of unending extra work? If I could trust the maintainers to mostly make the right choices I could go along - with no more than an audit and perhaps an occasional tweak. But if they were making what I consider the right choices, I wouldn't expect to see such a debacle.
Entangling diverse processes into an interlocking mass is what operating systems are all about!
No, it's not. The job of an operating system is to KEEP them from becoming an interlocking mass, while letting them become an interacting system to only the extent appropriate. It isolates them in their own boxes, protects them from each other, and facilitates their access to resources and ONLY their LEGITIMATE interaction wherever appropriate and/or necessary. The job is to Keep It Simple while letting it work.
Your phrasing, and making a joke of this issue, is symptomatic of what is alleged to be wrong with systemd and the engineering behind it.
Your payback time on the cheaper service will be under a year to switch to Republic, and if you really use that little data, it will be more like 4 months after the new plans go live.
At a large scale, the internet was designed to route around individual problems such as this.
Can't this same principle be applied on a smaller scale?
Yes, it can. Just dig a whole bunch MORE trenches around the country at enormous cost.
The SONET fiber networks were designed to be primarily intersecting rings. Most sites have fiber going in opposite directions (with a few having more than two fibers going off in more than two directions so it's not just ONE big, convoluted, ring.) This is built right into the signaling architecture: Bandwitdth slots are pre-assigned in both directions around the ring. Cut ONE fiber run and the signals that would have crossed the break are folded back at the boxes at each end of the break, run around the ring the other way, and get to where they're going after taking the long route. The switching is automatic and takes place in miliseconds. The ring approach means that the expensive cable runs are about a short and as separated as it's possible to make them.
But cut the ring in TWO places and it partitions into two, unconnected, networks. To get from one to the other you have to hope there's another run between the two pieces, and there's enough switching where they join to reroute the traffic.
IP WANs have, in some portions, also adopted the ring topology as they move to fiber, rather than sticking to the historic "network of intersecting trees" approach everywhere. That's partly because much of the long haul is done on formerly "dark fiber" laid down in bundles with the SONET rings from the great fiber buildout (or is carried in assigned bandwidth slots on the SONET networks themselves), partly because the same economics of achieving redundancy while minimizing costly digging apply to high-bandwidth networking regardless of the format of the traffic, and partly because routers that KNOW they're on a ring can reroute everything quickly when a fiber run fails, rather than rediscovering what's still alive and recomputing all the routing tables.
= = = = =
Personal note: Back when Pacific Bell was stringing its fibers around the San Francisco Bay Area, I was living in Palo Alto. They did their backbone as two rings. There was only one section, perhaps a mile long, where BOTH rings ran along the same route. It happened to go right past my house, with the big, many-manhole repeater vault right next to the house. (I used to daydream of running my own fiber the few feet into the vault. B-) The best I had available, in those pre-DSL days, were dialup with Telebit PEP modems (18-23 k half-duplex) and base-rate (128k) ISDN.)
I never understood why the FCC didn't require cellular providers to provide the same level of backup power to cell sites as we had with the traditional POTS system. Even if you wanted to argue that it was originally a marginal value added service it became quite evident before we expanded beyond the A&B provider AMPS system that cellular was likely to displace wireline as the predominant terminal method in the future. I know there would have been some limitations to site placement in urban areas if they required a large battery room and a generator hookup but it would have provided us with a much more robust system. Perhaps they should require it for the fixed wireless installs that the telcos want to use to replace POTS.
Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.
