These things only verify honest people.

They really want you to use Meet.

They refuse enhance the open standard like VOIP and standard SMS, which is what Google Voice was. They are going all in on the closed ecosystem.

I get it, this is for their employees. Googlers first. They live in their email for their work.

But for the rest of us, I never touch Google Meet.

Buy the dip.

Let's be clear. Both of these companies lobby aggressively in California to not pay any increase in wages or benefits. They do not want gig workers to be considered regular workers. They lobbied against that state proposition. They won.

Sure, they revolutionized the taxi industry. But they are not profitable right now. But whatever, these companies will basically do anything but pay workers more (the amount of money lobbied spent is ridiculous). Anti-worker and anti-union practices. They can shove it.

And, if you are in a busy region with a nearby warehouse, I almost always get the items within 2 days even without Prime. I do have Prime, because occasionally I get something that comes from across the country and I appreciate the consistency of knowing when it should arrive.

Oddly enough, sometimes I order things I expect in two days and make plans around it; only to have Amazon deliver the next day (once I had an item the same day when I ordered very early in the morning). I prefer consistent times over anything else.

I've tested all these attacks myself, and with a good directional antenna with a high transmit power the attacker can be pretty damn far away from you.

Even if you lower your router's power output (a very good first step to mitigate this attack), his directional antenna will allow him to pick up fainter signals.

Disable 2.4GHz if you can, and just use 5Ghz as there are far fewer high powered directional antenna available. The 5GHz signal also doesn't propagate as far.

If you find the location he's coming from, you can shield that with foil.

The solution for wireless could be a TCP congestion control change, such as Westwood+ which accounts for bandwidth by delay rather than dropped packets.

But even better is a simple proxy setup. The proxy handles the request at the AP for the client, and retransmits can occur over the much faster wireless link.

It's mostly a cost issue, since only recent APs are powerful enough to run a local caching proxy.

And pretty much everything you said is true in some sense. Given not so superb equipment for mixing, recording, and playback, simply having the slight room for aliasing filters and frequency information can improve the final product that gets output at 16/44.

But as the article says, if you do it right the first time, there's really nothing to be had going for more than 16 bits, and 44kHz, it should encapsulate the entire range of human hearing in any normal situation.

I'm really glad the article was posted. It cleared up some of my misconceptions.

And now I know the final product at 16/44 is just fine if done right.

This is true, but modern branch predictors are pretty good. Sandy Bridge reportedly is correct more than 80% of the time. So it really depends if having fast on chip DRAM (but a smaller amount) is more valuable than having L1, L2, L3, and RAM caches at differing speeds with their own predictors.

I'm guessing it depends on the application.

If Microsoft implements it right, it should be faster than NTFS.

Since it's copy on write, you can batch together random writes into a single linear write (while still maintaining consistency). They also mention having 3 allocators depending on the size of data to be written (because a one size fits all allocator is worse than 3 tuned to data size).

And considering it gets rid of some rarely used NTFS features, it also stands to be faster because it doesn't have to support as much.

Are you sure that's saving you power? Sometimes you have to initialize the device in order to activate the power saving features. It happens in Windows as well with wireless cards. The default state is "max power."

I agree generally, like AMD's bulldozer hitting 8GHz on a single core before failing to the limits of physics (even with extreme cooling). I'm assuming nobody will never be able to get more than 1 or 2 cores active (out of 8) while getting to 8GHz on that architecture.

But these days, the chips run in multiple clock domains. I believe the Intel chips are separated by a base clock, L3 Clock, Core clocks, RAM clocks, and bus clocks. The architectures are moving ever toward asynchronous operation in order to pack billion upon billion of transistors on a package without having to synchronize them all the time.

Microsoft is doing the right thing here. They are dropping the antiquated Win32 API and its bloat, in favor of a new universal WinRT API that targets both ARM and X86. Furthermore, it consolidates everything (Silverlight, Win32, WPF, .Net) into a cohesive API that you should be easily able to port to. If you cannot easily port to it, you're probably designing some custom business app that has and never will upgrade. Sorry but the new Windows isn't for you.

People have been asking Microsoft to the drop the bloat for some time. The security has been a nightmare because they've had to maintain the old unsecure model for the sake of compatibility. This clean break allows them to fix the permission model so that each App asks and gets only the permissions it needs during the install (like Android).

I like this change. Apps will now have to focus on doing one thing really well (and being able to connect and share with other apps) instead of being one-stop bloatware packages. Have you seen new contract API that facilitates this? It seems to follow the UNIX philosophy of doing a single task and being to pipe that output to anywhere.

Reading the paper, it seems the proposed protocol for key exchange forces a wait time of 17ms, and then hashes the packet to ensure it doesn't get modified (forcing the use of slots and keeping the air open during attack).

The only problem I see is that you could easily use this mechanism to effectively DoS the network by making it wait for the CTS packets constantly while the protocol rejects the bad check-summed packets.

But I guess that's a minor flaw since it's already trivial to DoS wireless networks in general.

Here's to hoping this actually gets widely implemented.

Is there an advantage to a reformat?

You say it creates a recovery partition? But when I run it from an existing Snow Leopard install, my existing Snow leopard partition size remains unchanged. I don't have an extra partition after installing Lion.