Yum is pretty solid. There are only two things that kind of bug me about it:

1. Sometimes (especially when dealing with third-party repos e.g. RPM Fusion) you'll see what looks like the same package listed 4 times. My guess is that there is a separate package for each architecture. Simply omitting the package portion from the name when you run the install command seems to pick the correct package(s). Still a bit confusing though, especially in cases where there are other compounding factors like different graphics card chipsets (I think I saw 16-20 different packages for NVidia drivers at one point).

2. You are kind of forced to use third-party repos, because the official repos don't contain any non-free stuff (MP3 codecs, binary drivers for NVidia and AMD cards, etc.) Setting up the third-party repos isn't as dummy-proof as setting up PPAs in Ubuntu. (It's a pretty straightforward but largely manual process, unless I'm missing something. And if I'm missing something, then that is a problem in itself.)

And for a while the KDE Package Manager integration was broken as well, but I think that's been fixed for a while now. Overall it's much better than it was, but I'm still more comfortable using apt in Ubuntu (although as a distro I like FC better).

I agree, and would add to this that when tracking down issues with multi-threaded apps (deadlock, race conditions, etc.) the debugging instrumentation itself may mask the problem. Instrumented code executes more slowly, which may completely avoid the issue, and often you have to freeze other threads so that you can follow the path of a single thread. Most of the time it's simpler to throw a thread ID and state information in a debug log and run the code several times to repeat the behavior, and then walk through the logs to figure out what is happening.

In most JEE apps I've dealt with the only think kept alive is HTTP session state. Using a framework like Seam, a session- or conversation-scope component can be instantiated, have the session state applied, have its dependencies injected, process the request, and then be disposed of (although typically object pools are used to avoid the overhead of instantiation).

(Granted, vanilla JSF is prone to session-scoped managed bean proliferation/abuse. I personally have never managed to get very far with plain JSF before inventing some sort of conversation scope. The view model and its state can get rather large and tends to pollute user sessions, but that can be stored on the client side.)

In the rare case where a stateful session bean is needed (hardly ever) a similar thing happens with passivation and activation. But more importantly, stateful session beans are released at the end of a conversation/unit of work and are most certainly not kept alive for the duration of the users session.

Memory was never really an issue for us (except maybe permgen space due to Hibernate proxies). The problems I've had dealt with resource contention in the DB due to JEEs rather aggressive transaction management defaults and distributed transactions. PHP et. al. avoid such issues by leaving transactions entirely in the hands of the user and RBDMS providers.

If you're writing an application (data model, web services, etc.) then JEE is a good choice. If you're writing what is essentially a group of pages with some dynamic bits, then PHP, Python, etc. is probably a better choice.

Depends on your phone. I bought an HTC a while ago (my first smartphone) and thought it was pretty neat. I was surprised at how much different other Android phones were when I compared them, particularly the lack of consistency between the various apps. (HTC includes their own media player, mail, calendar, etc. so it all looks the same throughout.) I have a few gripes with my phone, but on the whole I'm very satisfied with it.

That has been the default for some time now. The only reason to install sun-java-6 is if that is the target runtime for, say, a production Java application you happen to be writing, especially if you rely on esoteric command line arguments (-XX:MaxPermSize for example). So while it's not the end of the world, it certainly will cost a day or two of productivity for many Java developers and admins running Ubuntu as they will need to install the official Oracle packages, update alternatives, change symbolic links, etc. on any workstations and servers that are currently running sun-java-6. For developers targeting Java 7 this might not be that much of an issue, since the Oracle Java 7 packages are based on OpenJDK (although the commercial Oracle Java packages do have JIT and GC optimizations that may could result in unexpected behavior between dev and production environments).

It would be nice if Oracle would extend the distributors license indefinitely for Java 6. Not sure why they're bothering with it now, other than branding.

While this is true, the part I find most disturbing about CarrierIQ is its capture of HTTPS request details and traffic over Wifi, neither of which would be available to the carrier otherwise. Yes, meta data related to calls are logged... carriers are in fact required to do so for a number of reasons (billing, mediation, audits, and servicing subpoenas, etc.) However, I do not subscribe to a data plan and any traffic I send over a Wifi connection should be between me, the Wifi router, and the remote machines I am connected to, particularly when using "secure" protocols like HTTPS.

File a complaint. It takes a while, but they do actually process these. I filed several of them years back and recently received E-mails notifying me that they had taken action. You don't get any money out of it, but it's my understanding that the companies in violation are fined, so filing enough complaints will (hopefully) provide a disincentive to harass people.

Isn't this what Ubuntu was trying to achieve with Unity and Gnome with Gnome Shell? The smartphone/tablet market is the one that's growing right now, so everyone's chasing those dollars.

(Incidentally, I happen to like Gnome Shell and it seems to work well with large desktops and multiple monitors, so it seems like the goal is achievable.)

I suggest QMail. The code isn't that big, it's well written, and it's modular (lots of executables calling other executables). I wrote some authentication plugins for it about 10 years back and as I recall it wasn't too hard to figure out what was going on.

Fall in Florida starts somewhere around November.

AMD CPUs come with adequate stock coolers, especially the 65W range. Both motherboards I've purchased in the last 3 years each came with 2-3 SATA cables (as well as old school ribbon cables).

I put together a quad core Athlon system with 4 GB of RAM (integrated sound/video) for less than $300 ($400 including a 20 inch LCD 1900x1080 monitor) over 2 years ago, so it wouldn't surprise me at all that a halfway decent system could be had for $200-$300 (including monitor).

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

As much as I like AMD, the stock cooler that came with my Phenom II X6 was garbage. It was incredibly loud and while CPU temps were acceptable they were borderline high/critical. Contrast with the Zyman I replaced it with, which ran silently and dropped temps by 12 degrees on average. Having gone through that, I'd definitely take a discount on a high-end CPU without a heatsink and provide my own aftermarket cooling solution--I don't think I'll plan on using stock coolers anymore...

It's simply a matter of terminology. The PC is going away, but workstations are here to stay

My previous company provided managed/hosted communications services and we used PoE quite a bit. When deploying 100 or so phones it ends up being cheaper to put in a PoE switch than it is to buy power bricks at $5/pop. In the consumer space you only have, what, maybe 3 devices on a switch? At home I have an Ooma, LinkStation NAS, and my computer. PoE only provides enough power (~25W) for the Ooma (maybe), so as much as I'd like to get rid of three power cords it just isn't possible or cost-effective.

100W USB might work for the NAS and the linkstation, but to eliminate the extra cord it would require support for IP over USB and an upstream USB NAT or bridge device. (It would be neat if the standard evolved to the point where every device could request an IP address from the host and be treated like a network device.)

So this technology might work for:

1. Charging larger devices (netbook, tablet) from a PC / standardizing charger form factor
2. Powering and driving external displays
3. Some kind of smart power standards ... being able to put a powered device into sleep mode from the host or vice versa using signals, and adjusting the power supply/draw accordingly.