sorry, not reading the article. But doesn't an iPhone automatically fallback to cellular data when out of wifi range? I'm pretty sure mine does.

What's new here? Is it faster? More fault-tollerant?

I think I answered my own question, and the answer is obvious:

They distributed this malicious program as an SDK with source code inside the Xcode install. So it's not just a binary library that gets linked against, it's the code too. Is that correct?

Ok, I read the article you linked to. Very interesting.

What I do not understand is how the source code was "found". I understand how to use a disassembler, but that would not yield such readable code.

Can you comment on this?

Thanks for linking to the article.

Well I'll be darn, you've proven it. A bunch of folks at a conference were able to use systemd.

I have several systems running systemd. It's not impossible to use or install. But it is not as robust. It is different. And it did cause me a lot of pain on several production servers. For those of us who work in the field, we know a turd when we see one.

For those of us who depend on support contracts and certifications, such as yourself, I guess it's not as big a deal.

And one more thing:

What the heck is "standard modern software"?

How is systemd "standard"? This is brand new. There is nothing standard about it either. It is completely different. People like myself are complaining because it is NOT standard.

And modern? I suppose that's open to interpretation. An apple watch is modern. So is Windows 10. As is OpenCL. What the heck are you trying to say? Because it's modern it is automatically simple to admin? WTF

And who is this "We" you speak of?

Not eating the cake.

It's not incompetence, I assure you. My inability to get systemd working at my level of standards speaks directly to the level of readiness of the systemd packages, distros, and maintainers.

I suppose every person complaining about systemd might be totally incompetent. Maybe it's only the new kids fresh off the ubuntu express that have issues with it. Perhaps most people that are really smart and analytical like systemd.

Or. maybe it really isn't ready. Maybe it is a big mess. Maybe it was pushed early in distros to sell more certifications and paid support contracts.

I mean, one guy (an AC) replying in this thread was using it without even noticing it. Do you think he really knows what's going on under the hood or is he just another ubuntu desktop user that thinks gnome is his operating system?

Despite your judgment of my non-expert status, I am an expert.

I have learned many new technologies within hours on linux. There is a sort of common "flow" between technologies on linux. Same can be said for FreeBSD and other unix-like systems. I have admin'd basically every version of unix you have ever heard of. Everyting from irix to solaris to a/ux to aix. My first linux install was off floppy disks. I've worked on corporate, university, and government platforms. I've been everything from a kernel device driver developer (atheros wifi drivers) to large cluster admin to net booting macs off a FreeBSD NFS cluster. I'm not new to this at all. Not to say that you were in diapers while I was compiling linux from scratch, but I've been there.

That is why I feel such a distain towards systemd. Yes, I could have dropped everything, read all the documentation, checked out the source code, and probably figured it all out sooner or later. But what a PITA. What I had before worked, and it was easy to maintain. Sure, init scripts lack elegance. So ok, address that. But pushing systemd is not a solution. Systemd basically cost me a lot of productivity. There was no gain, no benefit to my installs. I have a few computers running it. I can't see any advantage other than that they are "up to date" with trendy linux packages. And they boot faster (when they boot fully, that is).

First off, thank you for your well-written reply.

Here's what I worry about: If we design core linux technologies (i.e., the kernel, kernel modules, udev, init system, etc) such that they cater to companies making money off supporting linux (red hat), then we may also loose something else in the process. (We don't have to, the two aren't mutually exclusive.) It has nothing to do with the existence of closed-source linux software and commercial deployments. It has to do with the overall closure of linux. There are companies that would love to make linux something like MS or Cisco where individuals need a new certificate every year in order to work government software contracts and big corporate installs. Systemd does facilitate that. Besides from being far from ready for the real world, systemd is overly complex. Systemd is a big single point of failure. Systemd has binary logs. Systemd is vastly more difficult to troubleshoot than Sys-V init (and yeah, Sys-V was a convoluted string of shell scripts, but it was pretty easy to follow through and get working). I mean, you've read or experienced these things, this is not really anything earth shattering.

So what I feel, is that the move towards systemd is a move away from the roots of linux. It's away from the days where you could install linux and start an ISP in a garage. It's like the writing is on the wall.

Let me ask you this: If they decided to do away with every single file in /etc and replace it with a binary-format database, editable only with a special program for gnome-3, would you like that? It would be modern. It would be enormous. It might be faster than parsing text files in C. It would require everyone to learn something new. It would begin rather untested and probably be pushed out to every enterprise distro immediately. I mean, how far will can we go from the roots of our success before we are alienated and cause our own demise?

I'm all for a *better* init system. And there are parts of systemd that have some good merits. But it's way too untested, and beginning its linux life with far too many tentacles.

In a time where unix and linux are the dominant (or nearly dominant) operating systems (android, iOS, linux, Mac OS X, embedded products), we must be very careful of the ground we tread.

So that's why I would expect more from RMS. Not on the software architecture, or the quality of the code. But on the philosophy and ecosystem of linux.

I was around for those changes and many others.

Systemd is far more fundamental than those.

But hey, the proof is in the pudding. I spent two days trying systemd. I could not get it working properly. (This was with Debian, my favorite linux distro of all time.) Machines that couldn't mount an NFS point just booted to the rescue prompt. Networking didn't work. Many other issues. The whole thing just made me look at systemd as something that really has not been tested enough to have been distributed like wildfire. We can debate about the merits of a large overlord init+kitchen_sink system (and I think you can guess how I feel about that), but regardless, it is not ready yet. init is so tested and well-understood that, when compared with something like systemd, administrators and developers (and normal joe users too!) have a very good reason to hesitate.

If systemd has the potential to further commercialize the linux world (certifications, certified distributions, enterprise support contracts, etc), at the expense of the rest of the linux world then I think it is something we could use an RMS comment about.

They paid to get screwed.

Seems they are getting their money's worth.

Write code to test your code. Hit every edge case hard, every boundary condition.

All too often we tend to test our code by just running the overall program, but this is not good enough. Running the overall program does not introduce a wide enough range of input parameters to every function.

Write test code. Write code to log your inputs and outputs to files early in the development cycle. Don't get swamped down in the land of trying to debug code that was never written to be debugged.

I had many many tough bugs back in the day before I learned this lesson. Once I got this behind me, it was a lot easier.

Hmm... let's re-word that a bit and see how you feel from the other side:

Flying a drone in a populated area is unsafe in nearly every circumstance. Just because there's no malfunction doesn't mean there couldn't be. If the done had suddenly dropped altitude, would the pilot have tracked it like a skilled operator to land it? Would that have brought the craft down to a point where the pilot could have endangered neighbors? What if the drone landed in the pool? Was the pilot certain that in all cases his flight-range was clear before flying? These are all things which a responsible drone owner thinks about.

I hope the pilot gets a big-ass fine (I'd hate to pay for his jail food out of taxes). I also hope the flier gets a fine for trespassing - or even just gets called into court and let of with a warning. The lawyers fees will probably be 10x what the drone cost to begin with.

Also, that would be willful interference.

  Section 97.101(d) of the Commission's Rules prohibits amateur operators from willfully or maliciously interfering with or causing interference to any radio communication or signal. 47 C.F.R. 97.101(d).

https://www.fcc.gov/guides/ama...

But hey, I think you can argue the situation calls for it anyway!

Then there's the water absorption problem. 2.4 GHz is used in microwave ovens for a reason. At a few KW, you'd basically cook the drone in the sky. Hope you don't have any SWR, it will be a complete disaster on your feed.

73.

Try this one out: remap the upper numeric keys from numbers to the symbols they have above the numbers. When you need a number, hit shift to get the numbers or use the numeric keypad.

I find it very annoying to hold down shift so often while coding. I almost never use the upper-row numbers as numbers, but I hit a lot of symbols coding in C and C++. I definitely use the symbols more, why do I have to hit shift to get to them?

Just look at a hunk of your favorite OSS project's code. Are there more numbers or symbols?

Granted, any facebook/gmail computer user wouldn't get this at all...