You cant trust a manufacturer to be truthful

Re: Fight Club. In most instances, they (manufacturers) are the ones instituting the recall, presumably based on numbers and figures.. NHTSA (I'm in the US) will document the recall if it is justified, and the manufacturer is always the one paying for for parts and work and documentation and mailings and phone calls and....

In some cases, it seems the NHTSA will suggest -- or in egregious cases, demand -- a recall, but in -all- cases it is a manufacturer recall.

If the NHTSA demands that Toyota or Hyundai recall a lot of cars for something, then of course the NHTSA should be public with that -- as well as Toyota or Hyundai.

If Toyota or Hyundai recall on their own, then of course they should notify the NHTSA and then all related parties should also publish that.

But I should still be able to go to toyota.com, and get proper, up-to-date, recall information for a Toyota that I'm looking at buying or already own. It should be the first place I look, because (again) if Toyota is involved in a recall of their stuff, nobody will know more about it than them.

It's really no different than changelogs, errata, and bugfix releases on important software: We don't rely on the government for that, nowdo we?

Nay. If I want to know if AES is secure or not, I look to the vendor and peer-reviewed studies -- not the government. If I want to know if Windows 8.1 or 10 or whatever is a good step, I look to third-party reviews or the vendor website, not the government.

I propose that people aren't as dumb as you suggest. If they're smart enough to look for recalls before buying, then they're also smart enough to find those recalls without government intervention and expense. And a manufacturer, in any published recall, will always have more up-to-date information about a particular vehicle than any other party aside from, perhaps, the original owner.

If recall information is not published clearly and accessibly on manufacturers' websites,. then that is a failure of legislation and capitalism, not of a lack of a central repository.

Because again, if I'm looking to buy a car and I want to know what that models list of official issues are, why would I ask the government? The companies that both made and recalled the broken thing should foot the entire bill, even if it requires new laws to promote this behavior.

Some people have found that government sites are relatively accurate, compared to the other sources, or at least more accountable.

There can be no source more accurate or accountable than the manufacturer, as they are the body charged with implementing the recall, and are also the ones with $billions at risk.

Which of the following is more accurate:

A. A group of people reading the same newspaper
B. An orator reading the same newspaper to the same group of people
C. A transcriptionist transcribing the orator's speech and posting that transcription to Facebook
D. ...ad absurdum

OP's question, stated differently:

Why should the government be the main source for recall information on the Internet ?

Your response:

Besides, if you're buying a used car, this is an easy way to see if it is on a recalled list since you wouldn't have been notified by the manufacturer.

My thoughts:
If I'm buying a used car, presumably I know who manufactured the car because the car will be littered in badges proudly proclaiming who, exactly, built and may have subsequently recalled some part of the car. Whether a Kia or a BMW or a Lincoln, I should be able to go to kia.com, bmw.com, or whatever, and find the recall information.

I should also be able to find if the car has been serviced for any of these recalls.

I don't need my government to save me the gross and unjust burden of typing "2010 toyota recalls" into Google (which, presumably, would quickly populate with accurate results, as Google tends to do, in the absence of government intervention).

(Disclaimer: I'm a bleeding-heart liberal with a strong like for social programs, and even I think that the government has no business in managing recalled cars.)

That's one issue that I hadn't heard of, but it makes sense: Of course the wifi chip, in an age of nearly-universally-smart NICs, should be able to filter broadcast traffic without waking up the rest of the system or even generating an interrupt...unless an application is actually using broadcast traffic.

The other issue is WMM, which is a function that requires support from the access point. It involves some packet scheduling, rather than shout-ASAP-into-the-collision-domain that Wifi was initially designed to do. This lets the RX portion of the radio to sleep when connected to an AP, whereas without WMM it cannot.

1. Can be taken further, in a manner not dissimilar to disabling the retarded pre-load-at-boot that such things as Open Office and Adobe Reader like to do on Windows:

Keeping seemingly-innocuous apps from doing non-productive things, triggered by system events that they have no business keeping track of, is something I've found to be very good for both performance and battery life.

As an example Pandora, the popular music streaming service, wakes up (runs) on all of the following universally-useless intents by default: After startup (why?), locale changed (eh?), application replaced (any app!), timezone changed (!), time changed (!!).

I don't want Pandora to run on boot, or any other time that any of those things -- booting is already slow enough as it is. And what business is it of Pandora's when I update an application? I want Pandora to run when I run Pandora.

I use Autostarts to do kill these hooks, and many other hooks for other apps. (Requires root and Xposed,)

2. Turning off radios helps, but not like you think it does. Modern Bluetooth sips so little battery in the idle state that it's silly to bother with adjusting it if you use it for anything, ever.

Manually GPS off is laughable: It's -always- off unless an app (navigation, etc) requests access. Some apps do use GPS when their needs are better suited using cell/Wifi geolocation (Weatherbug's first Android releases did default to GPS years ago), but I don't see it anymore because.... Rule #1: Look at permissions when installing...if an app doesn't need to know precisely where you're at and requests GPS access, just find another app.

One radio does make a difference: I found massive improvements in battery on VZW by having disabling LTE when the screen is off.

By default, both the LTE (data only) and CDMA radios are always on (this is how voice calling works), and I don't care if I have fast data if I'm not looking at the phone.

3. Yep. A good ROM will also disable LTE when connected to Wifi. Another big improvement: Turn on WMM in your access point if there are options for it. Without WMM, the client radio is always listening for a packet when connected, with WMM packets can scheduled and client is allowed to sleep for a short period. (This seems to be enabled by default on home routers lately, but it wasn't always the case. Hence the option in standard Android to turn off Wifi when the screen is off. WMM is what makes Wifi battery-friendly, and without it it can be very thirsty when connected, even if seemingly idle.)

4. I wish. (VZW.)

Also: 5. Greenify FTW.

Care to share the name of that mysterious ROM?

Sure thing!

Liquidsmooth. Running on a VZW Motorola Droid Bionic. Beautiful, simple. Fast. Easy.

Yeah, as if Cyanogenmod is ever going to release anything other than an Milestone release.

Srsly. They ditched 10.1 for 11, when 10.1 wasn't even yet stable? It's now most of a year later, and we still don't have a properly-stable, just-works release that doesn't change once a month?

And I say this as someone who actually likes Cyanogenmod, but found another AOSP 4.4.4 build that actually lets me use my multi-core >1GHz pocket computer with more than a thousand megabytes of RAM as it should be.

Nay, I have plenty of clue. But the private commercial networks I manage do not benefit from QoS, as all packets that transverse these networks are equally important and congestion is -- by design -- not an issue.

You really don't have a clue that it's even possible to solve this problem with a home gateway. Your perception clouds your vision.

Your loss, friend.

Now get off my lawn.

Again, you haven't used it. You're working with a theory, and really have no idea what you're going on about.

Latency increases somewhat under load (as it must), though not appreciably enough to affect any of the things we do with it. Jitter is very low as well. No matter how hard people or things hit the network, the user experience remains very responsive for interactive tasks...perceptibly the same as it is with an unladen connection.

This, as opposed to hundreds of torrent peers hammering away, one or more Netflix stream soaking up as much as it can get its hands on, and et cetera: Without QoS (and I didn't name it that, such terminology has been in place for quite a long time as relating to this sort of technique), this network was essentially unusable.

And now, it works reasonably. Individual TCP or UDP sessions are placed into groups with other similar sessions, and those groups have their own assigned priorities. This can be done by port, IP/MAC address, or deep packet inspection, or the amount of data the session has used, or even DiffServ flags.

It even has a fancy GUI that actually works.

You sound a lot like people used to sound back in the day, proclaiming that NAT (or ipmasq as it was more-commonly known at the time) could never successfully allow FTP, ping, or traceroute to seamlessly work. They'd list a lot of seemingly-logical reasons as to why it can't work and never will work, and then go on a long-winded rant about why either proxy servers or public IP assignments or at least one-to-one NAT is the only way.

Fast forward, and those people have STFU because -- gosh -- NAT works and does these things. They were ignorant of the possibilities of creative people making creative solutions.

I mean, sure: "Proper" QoS (ie: DiffServ and sensible routers with sensible queues and routes from end to end) might be nice. Maybe it even works on a private network. It doesn't work on the greater Internet, though, as you yourself say.

So rather than say "fuck it, I give up, there's nothing to do," I've simply solved the contention issues of my own grossly-overburdened last mile. And I've done it all from one side of the pipe.

If that seems impossible, then you're the ignorant one. There is a world of things that you did not learn in school, and some of them actually solve real problems that people experience. Nothing of this universe is so rigidly-defined that it cannot be adjusted in some useful way.

If you want to learn about it, though, download Tomato and spend an hour or two playing with it on a relatively-saturated network. Then read the source code if you still think it can't work that way.

Nothing I'm doing with QoS involves DiffServ -- at all.

That you proclaim otherwise shows that you haven't used the QoS features of Shibby's version of Tomato-USB.

And until you do, we don't really have much to talk about here.

The fact remains that I can rate-limit specific ingress UDP and TCP streams based on a number of parameters, leaving room in the otherwise-saturated pipe for other packets, using nothing more than an ancient freebie WRT54G and a small Shibby build.

How does this all work behind the scenes? I really don't care -- it's not my primary field of study. All I care is that it accomplishes everything that I said it does.

Apparently nobody here has used the QoS features in Shibby's version of Tomato-USB.

Torrenting and Netflix and gaming and multiple kids playing with Facebook and Youtube, all at once, all on 2Mbps of downstream while maintaining sufficient low-latency that interactive tasks and VoIP work fine?

Why not?

I did this just last night, as I have many nights before.

I'm perfectly capable of prioritizing my own bandwidth, thanks. I don't want my ISP prioritizing it on my behalf. Ever. At all. Not even a little bit. Not my wired ISP, and especially not my cellphone ISP where I pay by the gigabyte.

I'm not the person you're replying to, but: My (almost 20-year-old) car tells me when I have a brake light bulb out, and/or a failure in the brake light wiring and/or the mechanical switch that activates said lights.

When it tells me that something is wrong with the brake lights, I stop where it is safe to do so and fix the problem. I do this because I recognize the importance of showing the people behind me that I am, in fact, slowing down. (I also tend to have spare bulbs and a proper toolkit.)

I'm not suggesting that everyone would be so anal about their brake lights, but they should at least be informed.

With modern automobiles, where a network of microcontrollers is cheaper than a maze copper wires and multi-purpose LCD displays are standard fare, much of this functionality could probably be implemented in software alone.

And it should be. So people are at least informed that they're being jerks.

What sometimes confuses people is that Google also sells IT services

They also sell books, movies, TV shows, software, and hardware.

Which part of this very conventional process of exchanging money for goods and services involves me being a product instead of a customer?

I've been spending a lot of time away from my momma's basement* and have been mostly been hanging out at my special lady-friend's place.

She has a 2Mbps connection, and depending on who is visiting, there can be a half-dozen people actively using it. With her old router (a D-Link box that only supports stock firmware and DD-WRT), everyone hated the Internet here: It barely worked. There were nonsensical discussions about "how many people were using the Internet" when things would slow down.

With Shibby's version of Tomato USB, I set up some QoS rules on an old WRT54G. I gave her own laptop a slight preference, but really: With QoS, multiple independent Netflix streams are working OK, even though the boy streams Youtube almost continuously. The Sonos plays music from Spotify perfectly. Interacting with the Web is fast and responsive from all devices. Torrents don't bog the connection. Interactive ssh, RDP, and VNC are very usable.

Nobody complains now. Sure, downloads are slow, but downloads will always be slow here compared to at my own place in Mom's basement. Things just work, and the streaming stuff (except Sonos, which gets a high priority, because buffering audio is teh suck) scales to available bandwidth on a minute-by-minute basis, and it all seems to work fine.

Key points:

Prioritize small streams of all types: Who cares what they are, they'll be gone almost instantly anyway and their impact is therefore small. These are things like NTP, DNS, the initial handshake of every HTTP connection, and other little stuff.

Prioritize important stuff: The HTPC is probably a better streaming target than some stranger's iPod Touch who you gave your WPA passphrase to just to be a nice guy.

Progressively penalize larger transfers: A lot of loading a modern Web page is the initial HTTP handshake, and a mile of CSS includes. Getting these done quickly is not so expensive in terms of absolute bandwidth availability, but really does improve the user experience.

Eventually, the classes go to a "bulk" category: Something over a few megabytes, or somesuch: If the game/windows/whatever update takes forever, so be it, as long as you can still use the rest of the internet while that transpires.

One can also do the "deep packet inspection" game, which is well-supported in Shibby, and gain a little bit more control. But that's decreasingly useful as more and more connections are encrypted by default (and one cannot inspect an SSL-ish packet without also performing a MITM attack upon the whole connection).

Rant: This is what IP TOS flags are for, but they're almost universally useless because end-user programs STILL do not (or cannot) use them properly. But if they were used properly, I could totally accommodate that low-latency VoIP or interactive SSH session, at almost-zero expense to Netflix streams.

720p is HD. It's a perfectly cromulent resolution, is defined by ATSC (the HDTV specification for the US), is way better than the 480i we had for over half a century, and can be argued to be superior to 1080i for some content types.

There isn't anything wrong with 720p. Most modern flat-screen televisions (yep, I wrote that correctly: Most people don't have a behemoth TV) do native 720p at best, and it's actually just fine for the viewing distances and screen sizes involved.

That said, Netflix as of a year or so started doing (what they call) SuperHD. To my eyes (and no, I haven't done frame grabs to verify), it's 1080p24, and it uses almost all of a 12Mbps pipe (which I did measure).