I got a Garmin vivosmart 3, and it's just that. Unobtrusive, a week worth of battery life, shows the time/date and notifications. It supports notifications from most apps, not just calls and texts.
Haven't had it more than a few months so can't say how durable it is, but been quite pleased with it so far. Price is also a lot more reasonable than a "proper" smart watch.
Well you could always use the system mixer, at least on Windows, though I admit that's a bit of a hassle if your music is very varied.
I am happy that downloads can't be written wherever. Isn't that a good thing?
Sure, but that's no good reason to restrict downloads to a singular location. Allow extensions to select alternate download locations (tied in with a directory selector dialog), and allow only downloads to the predefined directories.
It's more like, "I read a Mercurial tutorial once and know how to use that."
The point is, you don't really need to do more to be comfortable with Mercurial on the command line. Things make sense there, unlike with Git which bleeds implementation details all over the UI for no good reason.
In addition; what add-ons that do exist do not seem to be nearly as powerful as the add-ons I used previously. That may be due to the modular design not allowing as much control of Firefox by add-ons, it may be because there simply hasn't been time for third party developers to come up with equally powerful replacements.
The WebExtension API is significantly more limited than the old API. A lot of it is reasonable, but some of it is for no good reason.
For example, one of the extensions I use allows me to save images directly to one of several pre-configured directories. This is no longer possible, as all downloads have to in the main download directory or a sub-directory of it. Because Google says that's a good idea, and thus so it must be.
So, this extension cannot be ported in any reasonable way.
Yes yes, I could use symlinks or junction points, but that's a major PITA for no good reason except ineptitude and/or laziness.
Whenever someone says this, ask them if they are comfortable with the command-line. The answer is always no.
I've used Mercurial from the command line for 5+ years, didn't even cross my mind to use a GUI for it. Git however is completely unusable to me without SourceTree. Git has a horrible UI, especially on the command line.
So can you point to one which can control the Wii and isn't a pain to configure? I'm genuinely curious.
Obviously it'll need to support activities (that's the whole point) and have plenty of buttons to map to different actions (like switching "sound mode" on the receiver as mentioned).
Smart phones are no replacement for a remote. Need the tactile feedback.
I got a Harmony Elite remote, with the Hub. What non-cloud alternatives are there?
I currently need to control the following devices:
- NVIDIA Shield TV
- Surround receiver
- Bluray player
- Cable STB
- Wii
- TV
Of course I need to be able to do things like switch modes on the surround receiver (Dolby ProLogic to pure stereo etc), subtitles for the bluray player, tv guide for the STB etc etc. And some of the devices are inside the cabinet, so external IR blasters are a must.
At least for browsers you can add an exception for the gov't certs that you trust.
I actually just started using them in the past year.
I bought a few Chromecast Audio's, and since I could I used optical cable to connect them to the amplifiers for minimum noise.
I also got a NUC not long ago, and wanted to connect the audio from the NUC to my desktop computer so I could listen to stuff on the NUC using the same headset I use for my desktop.
To do this I got a HDMI audio splitter, and fed that to my desktop. I tried using the regular 3.5mm line-out to line-in cable, but the background noise from the NUC was intolerable. So, I switched to using an optical cable which has zero background noise.
So, I'd say it still has a place, though the combined 3.5mm copper/optical jack seems to be a better solution going forward compared to the slightly awkward TOSLINK connector.
GigaTransfers per second, essentially the clock speed of the bus. The bandwidth can then be found by multiplying the number of transfers per second with the bus width, and adjust for the encoding overhead (8/10 for PCIe 2.0 and earlier, 128/130 for PCIe 3.0 and above).
So, 4x (lane) PCIe 4.0 can do 16 * 4 * 128 / 130 = ~63Gb/s or ~7.9GB/s.
Wikipedia got a nice table: https://en.wikipedia.org/wiki/PCI_Express#History_and_revisions.
One element is better branch prediction.
Here's a paper detailing the branch predicition improvements of the last Intel platforms and their impact on scripting language execution: https://hal.inria.fr/hal-01100647/document
Our measures clearly show that, on Nehalem,
on most benchmarks, 12 to 16 MPKI are encountered, that is about 240 to 320 cycles are lost every 1 kiloinstructions. On the next processor generation Sandy Bridge, the misprediction rate is much lower: generally about 4 to 8 MPKI on Javascript applications for instance, i.e. decreasing the global penalty to 80 to 160 cycles every Kiloinstructions. On the most recent processor generation Haswell, the misprediction rate further drops to 0.5 to 2 MPKI in most cases, that is a loss of 10 to 40 cycles every kiloinstructions.
That's an order of magnitude difference. In their their Python benchmark the Nehalem has an average of ~1.5 instructions per clock (IPC) while Haswell has an average of ~2.4 IPC, a 50% increase over Nehalem. The branch predictor is likely a big factor in this.
Of course scripting languages is a "worst-case" of sorts, but lots of real-world code feature similar indirection for which improved branch prediction helps a lot.
The advantage of ECC RAM is NOT about "oh, the system has been up for 2 years without a glitch, see, ECC RAM was a waste of time".
The whole point is that you you can see that there were no errors.
Indeed. I just had to reformat an Intel NUC as the filesystem had been completely trashed. Firefox had been a bit unstable on it, but well, that didn't trigger any warnings on my end. I also got one or two weird errors when running apt, but I was running unstable so again I didn't think to much of it...
Then after a couple of months it stopped booting. Turned out the filesystem was bonkers, due to silent corruption.
Ran memtest86, and one small but sequential range of addresses failed for every test.
However I'm astonished about the significantly "above Carnot" efficiency. I wonder how they actually calculate and how they achieve that.
A big part, from what I understand, is Homogeneous charge compression ignition (HCCI) or Turbulet Jet Ignition (TJI). AFAIK Mercedes uses HCCI, while Ferrari (which has the second best engine) uses TJI.
They certainly have lots of other tricks too.
The biggest difference between time and space is that you can't reuse time. -- Merrick Furst
