Wrong. The LGPL license of free Qt allows you to keep the source code to your program secret.
I think it was GPL in the long past but they changed at least 10 years ago.
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.
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.)
Anyway, I digress. Advantages of systemd are: [long list]
Those are all very nice things to have.
Unfortunately, for my needs, simplicity and understandability are far more important than a fast boot and feature-rich management of the runtime environment. I need to KNOW that things are being handled properly and securely. That's become far more important since Snowden showed us, not that the spooks were getting into our computers (which we'd already figured was happening), but how DEEPLY and EFFECTIVELY their technology and personnel are able to do so.
If the improved functionality is at the cost of burying the configuration and logging in non-human-readable form and entangling diverse processes into an interlocking mass under a complex and ever growing manager, the shark has been jumped.
Though Linux has been becoming (MUCH!) more usable with time, its configuration has been buried progressively more deeply under more and more "convenient and simplifying", but non-transparent, configuration management tools. Systemd is the continuation of the trend. But it is also a quantum leap, rather than another thin slice off the salami. So it has apparently created the "Shelling Point", where a lot of frogs simultaneously figure out that NOW is the time to jump out of the pot.
It's been a great ride. It had the potential to be even greater. But I think this is where it took the wrong turn and it's time for me to get serious about switching.
There's good reason to switch to NetBSD at work, on the product. (The code supporting the secret sauce is on the user side of the API and is Posix compatible, so it should be no big problem.) Porting my laptop, home servers, and desktops to OpenBSD now looks like it's worth the effort - and less effort than trying to learn, and keep abreast of, the internals of systemd.
Call me if somebody comes up with a way to obtain the key benefits of systemd in a simple and transparent manner, rather than creating an opaque mass reminiscent of Tron's Master Control Program. (Unfortunately, the downsides of systemd's approach seem to be built into its fundamental structure, so I don't expect it to evolve into something suitable, even if it's forked.)
As I understand the three major forks:
One (OpenBSD) is for having as secure a desktop/server/embedded platform as the maintainers can manage - important in this post-Snowden era (as it was, all unknown, in the era preceding Snowden B-b). It is based outside the US so it can incorporate strong encryption without coming afoul of US export controls.
One (NetBSD) is for developing network internals software and networking platforms (typically ported, when possible and not part of a proprietary product, to the others and other OSes.)
One (FreeBSD), now that its original purpose of getting the code disentangled from proprietary accomplished and the other two projects forked from it, is for making an open unix-like system run on the widest range of hardware platforms and devices possible.
Unless you're using your machine for building networking equipment or it's a new hardware platform under development, the choice seems clear.
The irony is that it could be seen as "karma" that Jobs basically committed "suicide by woo", refusing to treat his cancer with any recognized scientific technique for most of a year and instead trying pretty much every technique in the book popular among the sort of person who typically believes in karma.
So perhaps all of the woo stuff actually works, but it plays in with the laws of karma
Are we allowed to say that out loud?
According to the first amendment, the government of the United States can't stop you.
If the denizens of the largest religion of the Unitied States (Progressivism), or at least their media spokespreachers, decide to gang-shun you, there's still the other half of the population to interact with.
Fortunately, techies usually have to deal with real-world more than social issues. Unfortunately, PHBs have control of the money and have to interact with the fanatics. Fortunately, techies are noted for not being skilled on social fads and are given much slack. Unfortunately, that slack sometimes comes with a hook: The PHB tells his techies not to be a "lightning rod" and say/post things, in a way traceable to a particular employee of The Company, that might bring down the wrath of the pressure groups, make it look like his "herd of cats" really IS crazy and repell funders and customers, or otherwise make his job harder than it already is.
Which (mainly the "crazy cats" case) is why I started posting anything that MIGHT be controversial under pseudonyms. And a reference to the PHB's order is the origin of the slashdot pseudonym "Ungrounded Lightning Rod" (since slashed down to "Ungrounded Lightning" by changes to the slashcode that limited pseudonym size). And why, now that "ULR" has a large and valuable reputation (and though that reputation might help with job searches) I STILL don't out the corresponding "True Name" on any electronic medium.
(So now you know.)
In Linus' case, I doubt that even a gang-shun by the Politically Correct would have an impact, on his finances, his social standing, or the adoption of his work or technical ideas.
(Can you imagine, for instance, the luddites , or even Microsoft's PR department, trying to get people to avoid Linux and switch to Windows or MacOS, or avoid git and switch to Clearcase, Bitkeeper,
So have faith. Either he's right, and systemd will not turn out to be that bad, or his faith in systemd will end in tears, and then, he'll sit down and write a new startup management system that will kick everybody else's collective asses!
Or maybe somebody ELSE will write a kick-ass init system, and Linus will say "Hey, that's cool!" and promote it. Or the maintainers of a major distribution will adopt it. Or those of a MINOR distribution will - and user will migrate.
Linus is great. But why does THIS have to be HIS problem? The init system may have a bit of extra-special status and privilege, but it's largely NOT the kernel's problem. Along with the system call API it is THE boundary between the kernel guts and the user/demon/daemon firmament. It says to the kernel: "Thanks, I'll take it from here."
I read that in the sense of, "Let's say that I'm in the position of being a general manager", as a hypothetical rather than something to be taken literally.
My favorite feature is Birds Eye view, which uses aerial photos rather than satellite photos. Sometimes that can get you better info from that, since they usually have 4 different perspectives you can rotate through, and they are much closer and more detailed.
That was true, but Google was pretty quick to copy it. They now seem to have incorporated it into their 3D view as well, which makes panning somewhat better (and more importantly hides the worst defects in the 3D view by limiting the projection to a POV very similar to where the texture map image was taken from).
I find this an interesting statement. Running the numbers, I find that you'd have to be using a rocket burning something rather better than H2/O2 (we're talking Isp >500 just to reach escape speed, much less to reach the target rock) to allow two launches of a delta-IV heavy.
Huh?
The fact that a Delta-IV Heavy has a LEO payload of over 27 tonnes is a fact. You don't need to "run the numbers". As for the kick stage, I didn't specify a propulsion system - for all we care (since we haven't established a timeframe), it could be an ion drive and not even take a rocket so large as a Delta IV-Heavy.
Meanwhile, the Falcon Heavy is to make its first launch this year, with double the payload of a Delta IV-Heavy. And as was mentioned, the Tsar Bomba was not optimized to be as lightweight as possible.
And this entirely ignores that noone actually has a Tsar Bomba sized nuke available to be detonated.
Oh, and you didn't allow for a backup
It's almost as if I didn't add "with enough advance warning" for that scenario and leave what "enough advance warning" is unspecified. But if there's another rock the size of the Chicxulub impactor out there and we don't see it until the last second, we deserve to get hit - we're no longer talking about a 50 meter spec (Tunguska-sized), rather a rock with a cross section 30% bigger than the island of Manhattan. We're talking about an impact of a scale that happens once every hundred million years or so.
A more appopriate version of the BBC's article:
---------------
OMG - matti makkonen
---------------
WTF - mm just died @63! #txtpioneerdeath was father of sms & dvlped idea of txt msg with phones. @2012 msged BBC that txt would be here "4EVR".
--------------
shoutout 2 Nokia for spreading sms w/Nokia 2010. thought txt good 4 language. was btw mng. director of Finnet ltd and "grand old man" & rly obsessed with tech.
--------------
OMFG people!
It is not only possible, but the easiest option, to "blow them up Armageddon style" (minus the drilling and the like). There's a lot of simulation work going on right now and the results have been consistently encouraging that even a small nuclear weapon could obliterate quite a large asteroid into little fragments that won't re-coalesce, while simultaneously kicking them out of their current orbit. A few years ago they were just doing 2d calcs, now they've gotten full 3d runs.
Think for a second about what nuclear weapons can do on Earth. Here's the crater of a 100kt nuclear weapon test. It's 100 meters deep and 320 meters wide. You could nearly fit a sizeable asteroid like Itokawa inside the hole. And that thing had Earth's intense gravity field working against it and was only 1/10th the size of weapons being considered here. In space you don't need to "blast out" debris with great force like on Earth, you merely need to give it a fractional meter-per-second kick and it's no longer gravitationally bound. And the ability of a nuclear shockwave to shatter rock is almost unthinkably powerful - just ignoring that many if not most asteroids are rubble piles and thus come already pre-shattered. Look at the "rubble chimneys" kicked up by even small nuclear blasts several kilometers underground (in rock compressed by Earth's gravity). Or the size of the underground cavity created by the wimpy 3kT Gnome blast - 28000 cubic meters. Just ignoring that it had to do that, again, working against Earth's compression deep underground, if you scale that up to a 1MT warhead the cavity would be the size of Itokawa itself.
You of course don't have to destroy an asteroid if you don't want to - nuclear weapons can also gently kick them off their path. Again, you're depositing energy in the form of X-rays into the surface of the asteroid on one side. If it's a tremendous amount of energy, you create a powerful shattering shockwave moving throughout the body of the asteroid. If it's lesser, however, you're simply creating a broad planar gas/plasma/dust jet across the asteroid, turning that whole side into one gigantic thruster that will keep pushing and kicking off matter until it cools down.
The last detail is that nuclear weapons are just so simple of a solution. There's no elaborate spacecraft design and testing program needed - you have an already extant, already-built device which is designed to endure launch G-forces / vibrations and tolerate the vacuum of space, and you simply need to get it "near" your target - the sort of navigation that pretty much every space mission we've launched in the past several decades has managed. In terms of mission design simplicity, pretty much nothing except kinetic impactors (which are far less powerful) comes close, and even then it's a tossup. Assuming roughly linear scaling with the simulations done thusfar, with enough advance warning, even a Chicxulub-scale impactor could be deflected / destroyed with a Tsar Bomba-sized device with a uranium tamper. Even though it was not designed to be light for space operations, its 27-tonne weight could be launched to LEO by a single Delta-IV Heavy and hauled off to intercept by a second launch vehicle.
Always draw your curves, then plot your reading.
