The detail here as to where Musk went astray was in assuming bad faith on the part of Broder. All of the raw data that Musk described was good; if he had stated the facts he knew and then asked the question "How can we explain the discrepency?", that would have been a lot better PR.

Unfortunately this is the kind of thing that I don't usually see managers or marketers do well; the people that "stick to the facts" and know when they've strayed outside of what they know for sure tend to be engineers. Elon Musk has a PhD in Applied Physics so he obviously has a scientific background, but he's currently acting as the CEO which is a management position, and the transition from being a technical designer to manager unfortunately comes with a change of focus. That's my best guess as to why he drew an assuming conclusion here.

When it comes to the back-end of the "progress bar", it's essentially a widget that shows a percentage from 0 - 100%.
So the question actuall is, does the thing the progress bar is showing the "progress" of output a "percentage done" or not.
Sometimes the "percentage done" can be estimated or calculated, but sometimes it can't. Some programs (like 'dd') don't give any progress output at all.

What's annoying is when programmers show a "progress bar" that changes but doesn't actually show any progress -- so whatever they show is fake. That's irritating, because when that happens it means the user is essentially being lied to, and defeats the purpose of the progress bar. I'd personally rather see a message of "please wait while (blah)" than see a fake progress bar.

The latest place I saw a fake progress bar was in the Java setup GUI in Untange (which is based on Debian). Every single area a progress bar is shown in this GUI shows looping "fake" progress. Ugh.

Again -- absolutely not. I'm going to try to clarify this for you one last time.

This is a case where the Ham is transmitting on a ham band (not on a TV band), but the proximity between the Ham and the neighbor's TV antenna means that the neighbor's TV, which lacks an input filter to initially reject the Ham band, is desensitized by the powerful signal, and as such isn't able to receive the weaker broacast TV signal. The effect the neighbor sees is "I can't see my channel", but it's neither the Ham's nor the neighbor's fault as to why that is. It's also perfectly legal for the Ham to be transmitting, because the Ham is not transmitting outside of the Ham band, and is thus not interfering.

This cannot be filtered at the Ham antenna. The filtering has to be done at the neighbor's TV.

Absolutely not.

I think it's best if the original author would please name the particular products.

Unfair statement; this was a situation where firmware came out later, and also almost all hardware (video cards, hard disks, network cards, motherboards, etc) has flashable firmware. Even if you have a backup of the BIOS, that cannot always save you -- like a backup of a video BIOS when the videocard can't work because it's BIOS is borked so that the screen is always black.

That's not a fair statement, because the specific devices and firmware versions have not yet been stated, so your statement is completely based on an assumption based solely on your experiences, which may nor may not have any relevance to this hardware in question. Thus what you're doing is known as "blaming the victim".

Designed and tested with the filter, shipped without it because they're expected to be connected to Cable, AFAIK. As for confiscation/destruction, I don't think that's realistic, regardless of whether that's what's "on paper".

That wouldn't help at all because the issue is the TV being desensitized by a signal that is out-of-band for TV, but in-band for Ham radio. You cannot filter out the signal that you're trying to transmit, as that defeats the purpose.

Well, no, not in this case -- remember, we're talking about TVs receiving broadcast TV that are the problem -- the signal causing the TV a problem is coming from the TV antenna, and (generally) not from "leakage". You've got the right idea, though -- that the receiver needs to be isolated from the desensitizing signal. Some filtering between the TV antenna and the TV is all that's required to reduce the mount of the Ham transmission gets to the TV's receiver. The TV's receiver is in a separate RF enclosure, so the fact that the back of the TV is plastic isn't a problem and is thus (usually) a Red Herring here.

Basically that's where this is headed. "The more you tighten your grip, the more this is going to slip through your fingers." We're basically headed down the path of building our own weapons from scratch, just like what has happened in warzones elsewhere.

Actually in most places, it does, at least for Ham Radio operators, CB, Family Radio systems, wireless intercoms,and Wifi. However as you mentioned, these liberties also come with the restriction that the transmission not interfere with other frequencies -- thus we can give you our RF, but you should never notice.

There's one catch, though: modern TVs lack an input filter that they're supposed to have by design which would normally reject non-TV frequencies, because they're suppposed to be tolerant of out-of-band signals. TV manufacturers got permission not to ship this filter, because most TVs are hooked up to Cable where it isn't needed. However in the cases where a neighbor of a Ham is receiving broadcast TV, the TV can be desensed due to the lack of the filter and the close proximity of the transmitting Ham station. In those cases filtering needs to be added back to the TV to isolate it from the Ham transmissions -- it's my understandnig that this filter can be provided by the TV manufacturer upon request.

I've visited the GBT while it was under construction at the NRAO; there's another interesting feature of the site due to the location being surrounded by mountains -- which is that thunder from lightning strikes take a long time to dissipate, because they reverberate between the mountains. It's reallly something to listen to -- the rumble after the initial thunderclap lasts for about 20 to 30 seconds. :-) Somehow it's like a symphony to the soul.

Cool.

Well, sort of. Debian has a tool 'debsums' to check package checksums and thus installed package integrity. (You'll likely want to run 'debsums -s' to report only errors.) However this isn't installed by default, nor is it commonly discussed or advertised, whereas the equivalent for rpm, 'rpm -Va', typically is. So it's not that there isn't a tool to do the same job, it's just that it's not as well known. Likewise with dependencies; if one uses 'atptitude' you can get both forward and reverse dependency lists, and with 'deborphan' you can find orphaned packages that can be removed. [As you can probably tell, I'm more comfortable with these tools than with the RPM counterparts.]

I don't personally see major speed improvements in RPM (yum/rpm on Fedora) over DEB; and if install speed were important, Arch is clearly fastest from what I've seen. ;-) If zypper/rpm on OpenSuSE is faster than DEB I wouldn't doubt it, but that wouldn't be a motivator (for me) to switch distros.

:-( Yeah... it's a lot easier to "explain away" issues than actually try to help with them. From the point of view of the person "helping", it "solves" the problem. I see this kind of thinking a lot on LUG mailing lists -- it's frustrating.

Most hardware these says comes with UEFI (or soon will), but more to the point you cannot guarantee that you will be able to know whether the hardware comes with UEFI or not. And regardless, you own that hardware now, so telling you to buy new hardware isn't reasonable. I forget if FreeBSD requires a different solution than the Grub2 shim, but hopefully there's a solution for it soon too.

I read about it before running into install trouble because of it, but all that does is remove the surprise factor. ;-)

Took me a bit to figure out that LMDE = Linux Mint Debian.
During the "top 25 distribution" tryouts I had I tried it, and admittedly I like LMDE more than the Ubuntu-based Linux Mint. However as jimshatt pointed out, that will not solve the social problems that Debian has, because both Mint and Ubuntu want packages to go through Debian first... so as a package maintainer you end up being in exactly the same position as you were before.

:-( Secure boot is a nightmare. On top of some UEFI bioses not having the option to disable it, another option is required to enable "legacy boot" mode; where "legacy" in this case means "anything other than Windows 8". Some bioses allow disabling Secure Boot, yet still don't have a "legacy boot" option. :-/

What I'm really dissappointed by is that some manufacturers (Lenovo, for one) don't seem to include anything about UEFI bios settings in their documentation for laptops they sell. I recently had to do an install on a Lenovo P500, and on this box getting into the UEFI bios requires pressing a separate tiny button on the side of the laptop while the laptop is off. See the text on Page 20 and the diagram on Page 5 of the following document (which doesn't ship with the laptop):

      http://download.lenovo.com/consumer/mobiles_pub/ideapad_z500p500_ug_v1.0_july_2012_english.pdf

Matthew Garrett has a signed "shim" for Grub which the other distributions which will let them boot even when the "secure boot" option is enabled; so OpenSuSE will have this solved soon. Hopefully Debian soon will as well.

      http://mjg59.dreamwidth.org/20522.html

I started with Slackware, then switched to Debian in late 1999 and have been using it since. However I recently tried a bunch of distros, one of which was OpenSuSE (12.1) with KDE4 and I was surprised at how much I liked it. If I ever switch away from Debian, OpenSuSE would be one of my top choices. I also liked Arch (super-fast package installs, but there's no graphical installer) and Vector Linux (based on Slackware but with package management). I also liked Fedora 17, but for obvious reasons I don't currently consider it a condender. :-/

Concerning RPM-based distros I'm assuming you're referring to the improvements via YUM rather than RPM internals. (Correct me if this isn't the case.) Debian has actually improved on some of the DEB packaging tools; it isn't obvious because the development of DEB tools starts from the source package side first. I mostly like the Debian packaging system -- it's still the best package management system that I know of -- except that it's a bit complicated to create source packages, especially if you want to use Git while doing so. If I were to complain about Debian and reasoning for leaving it, it would be more along the lines of social problems within the Debian community rather than technical issues.