GT/s is not marketing fluff at all, really, and not started by just DDR folks. The term is used to unambiguously describe the base line rate of a channel. It has concrete definitions for the folks actual designing the PHYs on the bus. GT/s as base unit has been in every PCIE spec from at least 1.0 (and probably before). It's used to describe line rates for many channels, not just those used in PCIE. (i.e. DDR, various SERDES, etc. )

A single channel (or lane, or X1) PCIE Gen 8 device will have 256 GT/s * 1 channel = 256 Gbps (raw rate)
PCIE Gen8X2 will have 256 GT/s * 2 channels = 512 Gbps (raw rate)
Similar math for PCIE Gen8x4, Gen8x8, and Gen8x16

These are all raw rates that don't include and line encoding, nor various packet overheads.

The raw rate is an important design consideration for PHY designers, thus having a concrete definition is important for a formal specification. GT/s is commonly used in such standards.

This is a way of representing the raw line rate of a single PCIE lane. At a low level, this metric makes sense for those folks designing the PCIE PHYs themselves. The PCI SIG group will go into great detail into the PHY link, so in that context, this metric makes sense.

I'm alone in the house at the moment (so less phones). From my network gateway:

% nmap -sn 192.168.1.0/24 | grep "Nmap done"
Nmap done: 256 IP addresses (22 hosts up) scanned in 2.75 seconds

Probably need to peek at a few random ones, might restrict some to local only too many "smart" devices. Darned spyware "IoT" devices calling back to their masters...

I'm still waiting for some webforums type software to have an interface as simple, concise, and usable as trn. A quick "minimap" showing where I was in a thread, including what was read, and what was unread, and thread hierarchy. Simple keyboard controls for viewing.

I don't yearn for the pure text console view - I'm ok with more modern UIs. But I've yet to find *ANY* web forums that are as easy to navigate as Usenet TRN.

All-grain home-brewer here - there's all sorts of waste in the beer making process. A common metric for all-grain brewers is mash efficiency, and most recipes assume 75% - meaning that the average home brewer is throwing out 25% of the sugars that are left in the mash. Pro's chase mash efficiency for costs, and even some homebrewers can get a little obsessed with it. Actual efficiencies can be 10's of percentage points higher or lower.

As the article states, there's protein losses too, as wells kettle and fermenter waste commonly called trub. Any way one can reuse this waste is a good thing. Although as other's have noted major breweries, and even most craft breweries likely already have a customer for the spent grain. It's likely not wasted very much even today. But more potential uses for them can't hurt.

I share jmccue's solution as well. It's not really rolling your own encryption+security - one uses vetted security software (i.e. gpg/vi for me) in security conscious ways Is it perfect? Nope. But in my mind, better than "all your eggs in one basket" these normal password cloud services offer. In my opinion those products are a much easier target for social engineering type vectors. The actual "encryption+security" tools is hardly ever the nominal attack vector.

For my nearly 80 year old mom - I tell her to just write her (mostly) random passwords down on a (physical) notepad she keeps next to her computer. This works quite well.

Doesn't even make me a little squeamish harvesting my tomatoes from something like this. Other, perfectly acceptable fertilizers (Think worm-tea, chicken manure, milorganite) come from things normally thought of as "waste". And it's much better from the chemical concoctions being applied to traditional commercial crops...

Well - I won't argue that point too much. But keeping (at least some) of the things on human timescales is the primary goal with this proposal.

I like the random delay idea.

An alternative - just apply 85% capital gains tax on proceeds from securities held less than an hour. Exponentially approach 100% for gains held 30 minutes and lower.

The whole business of HFT stinks of gaming the system - in a way that's just going to eventually blow up in our faces - algorithms working against algorithms creating a chaotic feedback loop...

Count me as one of those who's not sure what I'm looking at? Does it hurt to label each axis? I've no idea what the x-axis is. Y-axis I can infer as energy use per capita - but why not label it as such? I've still no idea what the x-axis is and what the sloped lines are telling me. Where the slope occurs on the x-axis - what information content is this telling me? It's not date. The point on the X axis where the slope changes as I scroll the years - what does this mean? Does the scale of the slope matter?

(I get quite frustrated with data that's not properly labeled....)

It's a shitty disease.

(Disclosure, raising a child with UC, and have two other close family members with it. The pejorative isn't strong enough)

Is it CR/LF or just LF, or maybe LF/CR. 0x0d (\r), 0x0a (\n) choose one (or two). Dos2unix is your friend.

Let's resurrect VI vs Emacs arguments again too.

Whew - doesn't this smell eerily familiar to some William Gibson and/or Neal Stephenson fiction. i.e. companies basically having more power than many countries. I know it's always been in the background of late; But this story, to me, really brings up memories from some of those stories from a few decades ago.

Even if I support the companies actions this time... What about next time?

1:30 hour commute, while bad, certainly isn't "extreme" by most definitions. The shift starts at 4 a.m. Sure that's early, but early shifts have been around forever.
An hour and a half commute can regularly been seen just between SF, and the South Bay. That amount of time can probably be seen on the tech shuttles all around the SF Bay area at peak times.

There's nothing really new to report here is there?

Further result: Most injuries occur on Sundays. Conclusion: Stop playing on Sundays.