Despite my mentioning the Cree 4FLOW, I still recommend buying Cree's more-expensive but better-made bulbs. The 4FLOW costs less, but it has a much shorter warranty and isn't nearly as well made.

The 4FLOW would be perfect for a light inside a closet that's rarely turned on, but then if it's rarely turned on you might as well leave the incandescent bulb in there until it burns out.

I had a similar experience with fluorescents. I replaced most of the ordinary light fixtures in my home with special fixtures with a circular fluorescent bulb (not "compact fluorescent"). I liked the quality of the light and I figured I'd be saving electricity.

Then the fixtures started burning out. Sometimes it would just be the bulb, but usually it was the whole fixture. At first I replaced the fixture with another (at $20 per fixture), but eventually I decide it was stupid and I started replacing the fluorescent fixtures with ordinary fixtures that take standard bulbs. At the time I installed compact fluorescents. And of course the compact fluorescents, which would be easy to replace if they die, never die. (I don't care, I'm replacing them with LEDs anyway.)

As for avoiding burning your house down, I suggest you do as I do: buy Cree products. I get the top of the Cree line, the "TrueWhite" bulbs, but they have new "4FLOW" bulbs that cost less and run very cool.

The cheapest LED bulbs will be like the cheapest anything electronic: made at some random factory in China with possibly bad quality control and even possibly bad safety. Sounds like you had the bad luck to get a bad bulb. Sometimes it's worth it to pay a bit more for a name brand.

waiting for a good price point

I don't know how much these cost where you live, but where I live I can get LED bulbs at Home Depot from $6 to $20 depending on quality and brightness. They have an expected lifetime of 20+ years, and I don't have to change the light in that time. To me, this is a no-brainer and I've been buying LEDs for my whole house.

In fairness, I know that the power company where I live is subsidizing the bulbs, and absent the subsidy they would cost more. But it seems likely that you might be able to buy subsidized bulbs where you live too.

Also, I just checked the EarthLED web site, and without asking me where I live, the site showed me a deal: $100 for a 20-pack of LED bulbs. I've never heard of the brand ("Euri") but surely you could pay $5 per bulb for something that will last so long?

I like the Cree TrueWhite bulbs and I pay extra for them. LED bulbs tend to be a bit too yellow, so Cree developed a "notch filter" that takes out some of the yellow from the light, correcting the color. But now the light is a bit dimmer since some was taken out; so Cree puts a few extra LED modules into the bulb. Result: same amount of light, better color, consumes a little more power but not too much more.

I have also replaced all the 48-inch fluorescent fixtures in my home with Cree Linear LS4 fixtures at 3500K color temperature. Wow, it's so much nicer light and completely silent. Totally worth it.

If you are using incandescent bulbs, and you replace your most-commonly-used ones with LED bulbs, you will save enough money on electricity to pay for the new bulbs within a reasonable time. If you already have compact fluorescent bulbs, and you don't mind their light, then LEDs aren't guaranteed to pay for themselves right away and it might make sense to keep waiting. Otherwise, go for it.

It's interesting the headphone jack is still there since bluetooth chips are so cheap, easy to use, and are smaller than the headphone jack itself. I guess the problem for wireless headphones is powering them requires too many batteries.

Current Bluetooth headsets require the audio stream to be compressed using lossy compression. If you want the best audio quality, you buy nice headphones and plug them into the analog jack.

According to a post on soundexpert.org, Bluetooth audio has 721 kbps bandwidth. That's bits, not bytes. Thus the requirement for lossy compression.

Unless Bluetooth becomes able to carry FLAC or Apple Lossless with at least 2 channels at CD quality, the headphone jack is still essential.

And as you noted, Bluetooth means battery hassles while wired headphones always work.

Don't forget:
Overdrawn at the Memory Bank

2.1 out of 10 on IMDB.

On the other hand, I rather liked the adaptation of The Lathe of Heaven.

From TFA:

held up by a tangle of clean power foes, regulatory and financing woes, and Cape Cod homeowners afraid it'd ruin the view.

Who exactly are "clean power foes"?

This seems like using an epithet to delegitimize others.

I'm sure there are people who oppose this project for stupid reasons, like "it'd ruin the view". But I am equally sure that absolutely nobody opposes this project because it is too clean.

I suppose that if you looked and looked, you could find someone who is so certain that an ice age is coming that he wants all power generated by burning stuff. But even this imaginary guy isn't really a foe of clean power, he's just a fan of carbon dioxide.

If you want a really awesome chemistry set, you can buy one:

http://hms-beagle.com/heirloom-chemistry-set/

This was a KickStarter project. He was trying to raise $30K and he raised almost five times that much.

https://www.kickstarter.com/projects/1742632993/heirloom-chemistry-set

If you can't afford the full set, contact the store; the web page says they can sell any subset of the kit.

Hmm, if I ever make it to Kansas City I will try to go check out the H.M.S. Beagle science store.

How about a one-button waterproof cell phone?

I've read about phones where you program which number the phone calls, but I can't find any now. Maybe they are no longer sold.

But here's a phone that calls some sort of operator, who can then decide how to handle the situation. You need to pay a monthly fee for the operator but I think that's better for a 2-year-old than a phone that just dials 911.

http://www.greatcall.com/products/greatcall-splash

If you could find a 1-button programmable phone, and program it to call you, that might be ideal.

IMHO, the sooner the world standardizes on Python 3.x, the better. It contains numerous small improvements, no one of which is invaluable, but together which add up to a better language.

As for print as a statement, I only miss that for interactive use, and you can assuage the issue by using ipython with the --autocall feature enabled. And I like the simple way you can now control how the output is formatted and where it goes, and you can re-bind the name print to completely hook the behavior of printing. Overall it's a win.

The big shocking change is that you are now required to be careful about character encodings on I/O because all strings are Unicode. My own name can be perfectly written with 7-bit ASCII, but there are many people in the world whose names require more than ASCII provides, and Python 3.x programs will work out of the box for those people. I wish everyone using a web framework to build a website would use Python 3.x and be international-ready from day 0.

As for Python 2.6.x, there are some things in Python 2.7.x that I definitely want. I find it odd that you called out 2.6 specifically.

P.S. I agree with you that Python was already pretty darn good even in 2.x.

Pascal might be underrated but it doesn't matter. There is no place for Pascal in the modern programming world.

When I went to college, Pascal was the standard teaching language. I have studied it pretty thoroughly and I understand it pretty well.

Pascal was designed as a teaching language. There are features in Pascal that are stripped-down, and I think it was just to make the teaching easier. In particular, why must all goto labels be integers rather than strings? I'd much rather write goto cleanup_after_fatal_error than goto 1000. It was a tiny bit simpler to write a Pascal compiler because of this limitation.

If you know C and really want to understand why Pascal didn't win over C, get a copy of Software Tools in Pascal. Look at all the places they had to work around limitations in Pascal, and consider how to write similar code in C. In all the cases, I realized that they simply wouldn't have had a problem in C.

Also, after writing the above book, Brian Kernaghan wrote an essay Why Pascal Is Not My Favorite Programming Language and if you have rose-colored glasses for Pascal I suggest you read it.

C really is the king of the "third-generation languages". In its earliest form it had dangerously little type-checking, but in its modern form (where you use function prototypes so the compiler can check types) it has type checking similar to Pascal, with all the benefits that provides. And it has all the little things I appreciate, such as terminating a loop early using break. In Pascal, to terminate a loop early you needed to either clutter up the loop conditionals with an extra flag variable (early_exit or some such) or else you had to use goto to break out (with a numeric label target, of course).

"But wait," some of you are muttering. "I used to write Pascal programs and I remember using break..." No, you didn't used to write Pascal programs: you used to write Turbo Pascal programs. When Borland created Turbo Pascal they fixed all of the worst problems of Pascal, pretty much by just doing whatever C did first. I wrote a lot of Turbo Pascal and I liked it very much.

But this points out the biggest problem of Pascal: it was not well specified, and as a result it didn't work a lot of the time. Where a spec is weak, you tend to get different implementations doing different things, which is horrible for portability. The wonderful book Oh, Pascal! discusses the brokenness of the I/O in Standard Pascal, and the various ways that Pascal implementations work around the problem, and summarizes with Cooper's Law of Standards: "If it doesn't work, it doesn't stay standard."

For Pascal to have a niche, it should do something a lot better than C, for it is C that it needs to displace. But IMHO there really isn't anything it does very much better than C, and there are numerous areas where it's a non-starter unless it copies features from C.

Given the massive installed base of C, C isn't going anywhere, and that leaves no room for Pascal; Pascal does the same sort of things as C does, but not as well.

So when things are wrong a frequent reason to use such a command is used), it wastes my time to display something I didn't request and don't want to see.

When things are wrong, you don't want to see the recent log events to diagnose what went wrong?

It's a legit complaint if this display slows you down, but I'm amazed that you are so hostile to the idea. However, as a sysadmin I'm just a dilettante so I will defer to your expertise.

Citation needed? I seem to remember that X could also run as non-root before systemd.

http://hansdegoede.livejournal.com/14268.html

The main problem with systemd is that it is beeing pushed onto and by the mayor distributions without fixing the problems first.

Makes sense to me. I'm glad that Debian did the work to leave SystemD as optional.

0) Okay, I agree that I should have phrased that differently. Note that I didn't use a pejorative phrase; I didn't say something like "morons too stupid to understand the greatness of SystemD" or whatever. I really only meant to say "some people who strongly disapprove of SystemD do not want it involved in logging at all."

1) I hope you didn't intend to lump me in with "systemd people" because I'm not one. I am an interested observer looking in from the outside. To the extent that I care about Linux and its future, I care about SystemD; I've been trying to understand how good or bad it is.

But the vast majority of the criticism I have read of SystemD has been just opinion-based flaming. To read most of the posts on Slashdot, there must not be anything good about SystemD and the people who choose it must be deluded or fools or something. I wanted to push past that and understand why smart people might not reject SystemD.

for those of us that use 'sed' and 'grep'

I'm quite skilled with grep so I can query plain-text files just fine, but I'm not opposed to SystemD making a binary log with an index for its own purposes.

If you set up rsyslog or whatever, you will still get a plain-text log file, and you have the option to simply ignore SystemD's own log file.

Windows style 'Services' (your word)

No, don't lump me in as a "systemd person". And don't assume that I'm your enemy or something.

And don't ask "how are they forcing" again, that isn't helpful when I can't get just turn the package off and sysv init on.

In Debian "jessie" you can do just that.

https://wiki.debian.org/systemd#Installing_without_systemd

systemd insists on binary logs

My understanding is that SystemD makes binary logs for its own purposes, and that the binary features include indexes so it can very quickly answer queries like "what were the last ten things logged by Apache?"

However, SystemD permits continuing to run a time-tested conventional log daemon. The current recommended way to get network logging is to run rsyslog.

Some hard-core SystemD haters are still not happy, because the log events flow through SystemD on their way to the conventional log daemon.[1]

takes over vast chunks of functionality that it has no business touching

I'm not certain this really is the case. SystemD is a collection of services, and each one has a specific area of concern. The actual technical analyses I have read suggest that the basic design of SystemD is sound, and that it is doing things that people want to be done. For example, SystemD allows the graphics system (X.org) to run as a non-root user.

One criticism of SystemD that may have some validity: that the only documentation is whatever the source code contains this week. SystemD is being developed at a rapid pace and documentation may be suffering. This is one reason I am glad for projects like UselessD... they will force the SystemD interface to settle down a bit and be documented a bit better.

But I'll say it again: from what I have read (in technical analyses) the basic design of SystemD seems to be sound. The Debian technical committee that evaluated the situation concluded that SystemD was the best choice for Debian. (Then the politics blew up but that's another story.) Do you think that the Debian technical committee spent months evaluating SystemD and were just wrong about it? (That's not to say that SystemD is perfect. But something can be imperfect and still be the best choice for the future.)

makes it basically impossible to debug problems

I will not comment on this because I have no experience with SystemD yet. I have seen comments like this multiple times.

Perhaps, even if SystemD is the future, it should be adopted slowly and carefully in the present. Debian "jessie" has SystemD as optional which seems like a very good thing to me.

[1] I think that's probably an overreaction... if Red Hat can't get SystemD to reliably pass through log events, that would imply a level of brokenness that would preclude the widespread adoption that seems to be taking place.

Huh, I didn't think that was a troll when I wrote it. But it has been modded as Troll twice now.

Well, I really do prefer to give my money to AMD and I really would buy the fanless mini-PC in TFA.