• * Samba, yes, because it's a daemon.
• * KDE, yes, because it's a daemon
• * LibreOffice, no, because as far as I can see it is launched manually. Now, it may need to ask for system resources that may or may not be started at initial boot, but that's a easily partitioned block of code that can see if systemd is there, and run only when it is.
• * GIMP, no, LibreOffice comment applies
• * whatever, depends. If it's a daemon, there many need to be something added to the package, but it can be a well-contained block of code that runs once. If it's not a daemon, see the LibreOffice comment.

When I was looking at systemd, one thing I wanted to see in the documentation is how to convert my own home-brew daemons to interface with it properly. Specifically, how to take SysVInit based starts and convert them to use systemd and journald. (Ditto taking UpStart scripts and convert to systemd.) The result needs to work exactly like daemons running under SysVInit. I spent three weeks with CentOS 6 trying to get my daemons to work right under UpStart, and never did get the exact functionality. I had to go back to crontabs for some of the work! So this is not an idle concern to me.

One of the gripes I have is that I want the University of Delaware version of NTP running on my edge boxes. As the group there make tweaks to NTP based on their continuing research, I don't want to wait for another group to do a re-port. That's why I would like to see a published way to interface with systemd/journald that would have minimum impact on the rest of the code base for a daemon.

I can see where daemons need to change. But do they have to be rewritten?

You forgot satellite. But, aside from that, you are talking about people who don't live down the street from a movie house. For these sorts of people, a trip to the movies is only a part of an extended excursion, a day and evening, on the town. Usually, such outings are planned well in advance and anticipated by all in the family (or families). It's not "just a movie" but a broader social experience. One enjoyed at long intervals because of the effort needed to have the outing, and the total cost.

Do you remember your college days? Remember when one of the frats would have regular showings of classic movies within walking distance of the dorms? And the admission fee was enough to cover the cost of the film, the projector, and maybe some money for the frat's pot, but not so rich that you would have to skip eating for a few days? Some of the movies they selected were really bad...but some of them were very, very good. That how I saw Night of the Living Dead for the first time.

In one place I lived, the church high school students would have a "movie afternoon" for the grade-school-age children, showing 16mm prints of G-rated films. Those movies were open to anyone, young or old, who wanted to come. For the older kids, there were PG-13 films, that were acceptable to the church board, shown in the evening (keeping in mind the 9-pm curfew). The crew was all-volunteer, and the church owned the projector and screen, so the admission price only had to cover the rental of the film. On rare occasion, the adult service groups would provide punch and snacks after the film. (not before or during.)

Today, I usually wait until I can get the DVD or Blu-Ray from Amazon for those movies I really want to see, based on the trailers. The rest? I will pick up DVDs from the used-book store, or even pawn shops. So far, for 2015, the only movie I'm considering seeing in the theatre is Pitch Perfect 2, and only if I can see it in a deluxe theatre with a track record of throwing louts out.

You don't need to burn them to the ground. Just give them a taste of their own medicine: start by hijacking mpaa.org and sony.com, using the technology the MPAA embraces.

Last question first: those admins who haven't worked with large numbers of TCP-to-serial converters -- I'm talking 6,000 independent datastreams at the same time -- and forget how TCP buffers get filled from a 1000 cps steady-rate source when the converter calculates a RTT of 2 milliseconds over the local network between it and the server. A server running as a guest in VMWare, with no packet aggregation optimization in the host's Ethernet interface. Who never heard of the word "thrashing". Who never saw the guest's real-time clock losing time because of interrupt overload. Who never took a WireShark capture of a connection, to see just how many packets are created for each stream

Criticism on my English and my spelling from an Anonymous Coward? Like that's worth much. Yes, I misspelled some stuff, but that's because what I published was first draft done in a hurry. If it were an article for paid publication, I would have used a real word processor, with a real spell checker, instead of a stupid HTML form. (Free Republic, another forum I occasionally contribute to, does have a decent spell-checker in its contribution entry form.)

And I'll be the first to say that my memory is a photographic one, but the filmbase is made from Swiss Cheese. That's why when I design a system, I use a number of methodologies to minimize the dependence on memory. I tend to design from the top down, then revise from the bottom up. Repeat as needed to nail down the details. I also create use cases: "I'm x and I need to do y," and then I ensure each case is covered in the initial design specification. I'm also a great fan of concordance generators to identify and eliminate "overloading" variable names within a project. Ever hear of one?

I'm 61, and still love solving technical challenges and learning new shit, so I still code...and it helps that I have skills that many consider "antiquated." In the case of my current job, knowing intimately the details of RS-232 based communication and drivers for same -- how to correctly program the NS16550 and ASIC cell equivalents, and more importantly how younger coders MISprogram the chip -- puts me head and shoulders over some of the new grads. Having more than 40 years' experience in project life cycles also means I can set priorities that make sense. I'm willing to adopt any new buzzword that makes sense...but reject new principles where I can't see any advantage to the company and myself.

I've seen the results of a tendency for people to be distracted by "shiny", and work through the problems it causes. For example, I remember when my company embraced virtual machines without fully understanding our system and network environment...and we are talking long-time certified networkers who don't fully grasp how TCP buffer-fill management works and how it affects dataflows, even when quoted chapter and verse from R Steven's book TCP/IP Illustrated. ("He doesn't know what he's talking about.") I fixed the problem, and no one liked my solution. The fact it worked was lost on them. Se la vie.

I don't play nice with stupid or shallow people, so I don't have to worry about management. I was a manager for a while, and my employees said I was the best manager they had seen. What tripped me up is that I couldn't lie to customers, even when told to. That inability to lie convincingly cost me a nice job and pension, but it also cost the company a seven-figure breech-of-contract lawsuit judgement. So I will stay where I am, doing cool stuff, until the day I'm forced into retirement.,/p>

Unfortunately, the tendency of The Powers That Be to use heavy-handed government intrusion against those who would speak against their positions is a real problem. I'm not posting this anonymously because I don't expect retaliation to these thoughts; if I did think that someone "official" would take note, I would click that box. And before anyone gets their partisan hackles up, the abuse of government power is not the actions of one political party. Or the actions at one particular level of government -- intimidation occurs in some States as well as at the Federal level.

The NTSB says they recovered the engine and NOX tank. No evidence of explosion in those components. Now, perhaps you are thinking of a different kind of explosion, such as how BOAC flight 781, a de Havilland DH.106 Comet 1 exploded -- a fuselage failure instead of engine failure. According to forensics after the wreakage was lifted from its watery grave, inspectors concluded that the aircraft had broken up in mid-air. If SpaceShipTwo experienced a similar type of failure, it could explain how one pilot survived -- he could have been blown out of the aircraft like that captain flying British Airways Flight 5390, who found himself "out in the breeze" after a windscreen failure, and who survived only because he didn't get pulled completely free and fell.

Or perhaps you were talking about the 2007 ground test of the rubber-fueled engine, where the three engineers were standing inside the danger zone when the test went wrong. That's why you run tests, to find out if things do go wrong, and you take proper safety precautions. To compare that failure with this one just doesn't hold up -- they are two different failure modes.

Actually, EBCDIC was weird because it's tied so closely to 80-column Hollerith encoding. Back in those early days of BCDIC encoding (which pre-dated EBCDIC), conversion of card hole punches was done with actual wires, plus a few transistors (or tubes!). When the System/360 came along, the engineers used the same techniques to decode card column patterns "at speed". I learned this for myself when I had to write a driver for a minicomputer (GA SPC-16) to interpret the punches. I didn't have enough words to use a proper 4096-entry table, so I had to use the same tricks to do a 1-of-n selection of the digits field, and then use the three bits from that and combine with the five bits of zone field, and look up the correct value in a 256-character table. The generation of the punch solenoid pattern used the same table in reverse, saving space at the expense of CPU cycles. In a 16-bit machine with 32 users, space -- especially low memory space -- was at a premium.

http://en.wikipedia.org/wiki/EBCDIC

One advantage of doing the punch portion of the driver that way was that there was no way for anyone to cause the punch to generate "lace cards", like the earlier, clunkier driver did. Great way to destroy the card punch we were using, as the power supply in the external box was too small to drive ALL solenoids for ALL columns of a card, especially card after card. The Field Service people told stories of the damage they found at customer sites because of lace-card punching. The FS people were relieved when the new driver proved to prevent the problems.

As I recall, there was an "ASCII mode" in the decimal arithmetic instructions in the S/360 and follow-on systems so "zero and add packed" (ZAP) worked just fine in dealing with ASCII source data. The conversion of the sign was a bit of a problem, but most ASCII input didn't try to encode the number sign in the last character anyway.

Did you know that one of the early porting targets for Unix was a System/360 computer?

I do apologize, I was using the term "source" and "sink" in their engineering definitions.

It sounds like they're intending to draw a distinction between nodes that principally receive data from those that principally transmit data.

This has been the traditional way to measure the type of peering between two networks: are you a net supplier of data or a net sink for data. Networks with a high number of web browsers would be a net sink, because HTML requests have high ratio of data received by the customer to the data sent. Networks with a high number of web servers are just the opposite. Most peering arrangements make the assumption that there would be some kind of balance, so the data load across the peering point(s) would be about the same.

The Internet, as it has developed, doesn't work that way any more. You have massive providers on the one hand, then you have massive sinks on the other, and the balance goes away. The receiving networks have difficulty being compensated for the additional bandwidth they have to handle from the upstream network, which is where the heartburn sets in. "If you want to send data to my network, who pays the freight?" In telephony, the model has been "sender pays". In cable television, it's "sender pays" with the customer's being billed for the right to receive "unlimited amounts" of content (disregarding pay tv).

This last option is what some of the transit and ISP networks want to impose on the likes of NetFlix.

Internet Service Provider, or ISP, is an outdated concept. If you are a Big Guy like Google or NetFlix, you contract with a transit provider of carriage. If you are Joe Six-Pack, then you contract with a retail-level provider like Comcast, AT&T, or your local wireless provider. The two are completely separate businesses.

How separate? Cisco, in its certifications make a distinction between ISPs (CCIE R&S, Security), and transit (CCIE Service Provider).

In banking apps, they still do have holy wars for EBCDIC. Decimal math instead of binary math or (brrrrrr) floating-point math. There are still a lot of legacy systems running multiple levels of emulation, all the way down to 407 accounting machines.

There are times when I use a drive-thru. What I absolutely hate is the delay from the time I order until the time my food is ready to deliver to me. The reason: it takes time to cook. I understand that. So the ability to order "over my phone" means that there is an overlap between travel time and food prep time. So, I get to the drive-up line, confirm my order, pay, and then get the food, all in seconds. Instead of waiting in the car line, engine idling all that time. (No, I don't have an electric car...yet.)

This order-by-phone process has become standing operating procedure for me when I'm getting a pizza, because the 20-minute cook time matches my overall travel time to the pizza place. No time wasted. (No, my usual haunt doesn't have drive-up -- I'm expecting that trend to start sometime, too. If you can have drive-up funeral viewing...)

How about this? You enter the drive-up and place your order, only to discover the two people in front of you have large orders...and all you want is coffee, soft drink, or other beverage. You sit and wait...and wait...and wait. Car idling, of course

It used to be that the fast-food restaurants would prepare food in advance, and possibly have to throw out some of that "spec" food. During rush times, they can prepare some things in advance; during slower times, they don't. I think the "new" way is better in some respects, but it plays hob with wait time.

Could this be a play on the name of the War Games computer, WOPR?

Then how would the baby feed? With his eyes closed?

Editing error -- when I changed one number, I forgot to change the other. Nothing distracts like a phone call from someone both sobbing and screaming, "I need help!'.