somepig

No. POWER and PPC are decidedly not the same. the closest they ever came together was the G5's 970.

4xx and 75x were OK for embedded a decade ago, but today they're hot and power hungry. You can use them in devices where you can burn 10+ watts to maintain backwards compact with existing PPC code, but they're way the fuck too hot for a phone.

POWER and Power (formerly PowerPC) are similar but quite different. PPC has been in embedded (but generally not mobile) for quite a long time, but even then, the cores are still hot, power hungry, and poorly suited for mobile.

POWER is about as far from a good fit for most ARM applications as you can possibly get.

It's all about shoving a ton of hot power hungry multithread cores as close together as you can and running them at full bore.

regular "app based" is just OATH-TOTP in most cases. This uses a shared secret and the time to generate one time codes.

The Yubikey explicitly supports TOTP, and will happily store your secret on the key. You can then use Yubioath to pull codes from the Yubikey as needed.

I'm a huge fan of the ability to use either U2F or TOTP with the same hardware token.

I mean... that's my point. I can plan ahead and pay $12 to have something delivered and then heat it up myself, or I can pay $12 to pick it up already hot and ready to eat, on demand.

What benefit do you provide over the Indian place down the block with similar or even cheaper pricing? These prices are absurdly expensive even for us overpaid tech folk.

certainly won't disagree that it can be limiting to folks of some perspectives, but as someone who publicly has applied the sysadmin label for the duration of their career (starting in the early 00's), I've yet to see a downside.

I've been obscenely compensated for working on interesting projects for much of my career. then again, part of it may be due to the confidence that comes with focusing on my work instead of fluffing my title.

it never left. you've just been blissfully unaware of it, and now that you've discovered it, you think it is new for everyone.

everything in this article is what I do as a sysadmin.

part of being a sysadmin is practicing devops. not the other way around

most places

e2ee can be turned off client side (and is off by default until ux improves), and while I don't think it's possible with the stock home server, it seems entirely possible to patch the home server to reject encrypt requests, and only federate unencrypted rooms

for directory service, LDAP and web SSO are both supported

> the real value in ChatOps comes when Ops folks are issuing commands in the chat room

yeah, being able to let Slack act as your identity management for manipulating prod is a killer app. much like sticking a pistol in your mouth

not before a massive security incident or two.

yay for delegating prod infrastructure access controls to Slack

2) Drugs. This has been my number one use for cannabis. If I need to go to sleep early for what ever reason, I smoke a bowl, lie down, and am out in no time.

tmo is a combination of TTL and APN.

Stock android and iOS will use the tethering APN under the hood. LineageOS doesn't.

I'm presently tethered to a tmo phone on their cheapest unlimited data plan and see 20mbit+

You might consider reading up on reproducible builds. The majority of Debian packages can now be bit-for-bit rebuilt to verify the maintainer actually ships what they say they are.

freeipa has this

users with totp tokens can kinit using their password+totp in the password field. better still, if you use PAM for all your services, you you can define hbac rules allowing users access to specific services on specific hosts.

the caveat is that the freeipa servers must be available to provide authorization even once the ticket is issued. with x509, the authenticating host doesn't need to rely on a server for anything but CRL checks

nobody uses analog audio out in an HTPC use case. You send digital audio streams out the HDMI port.

Even a low end external ADC is going to greatly outperform anything RPi could ship onboard for a reasonable cost, and even if they did ship something onboard, at this point it would almost certainly just be a USB ADC, but onboard.

the entire reason the devices get public a public IP is because the firewall effectively isn't there. from the time u-boot inits the topaz chip, until linux controls the chip, it behaves like a dumb ethernet switch.

If I knew of any such patches, I couldn't share them for Reasons, but suggest poking around mv88e6xxx_initialize in u-boot.

sure, but the espressobin has a gigabit switch onboard. and that switch is controllable from Linux, and treated as a bridge device, easily manipulated from brctl.

while the rpi3 spanks the espressobin on CPU, the espressobin destroys pretty much every other dev board (including rpi4) in the price range with regard to network functionality.

the espressobin(2xA53) is way less powerful than an rpi3(4xA53), let alone 4(4xA72), but has a minipcie slot enabling you to add a WiFi card of your choice.

Additionally, the Espressobin has a Topaz ethernet switch onboard with 4 ports (1 to the SoC, 3 as gigabit ethernet rj45). This is both really spiffy and scary (see my other post). The spiffiness is that the switch can be controlled by Linux and is integrated with bridge-utils. It looks and mostly behaves like a software bridge, but the packets never hit the CPU, only the topaz chip.

some ISPs will happily assign public IPs to any hardware address that sends a DHCP request. This means while the network segments are bridged, all local devices are potentially obtaining public IP addresses and are exposed to the internet at large.

This is problematic if you have home network devices with vulnerabilities or services running on hosts with the assumption that the host will only ever be on a private network (unauthenticated file servers, etc)

There is also an issue with the number of devices exposed to the ISP -- many will issue an address to the first device they see on a link, then ignore all other devices until the lease expires or is released. That means your PS4 may get a lease before the espressobin's Linux takes over, and the ISP will ignore the subsequent dhcp request from the espressobin.

Oh the Espressobin. The poor thing has a dozen or so variants, and each one requires a different u-boot image. Fortunately they ship with the u-boot image on SPI flash, so in theory you could just let it be and not worry about the variants... except for the massive security issue where the stock u-boot bridges all ethernet ports.

With a stock u-boot, from the time the bootloader brings up the ethernet switch until Linux takes over it with dsa and bridge-utils, your LAN ports are directly bridged with your WAN port.

expect a bricked firmware and/or child porn repository within 72 hours

Fun Fact: Some carrier throttling works by throttling packets with an unexpected TTL. Android has a default TTL of 64.

You most certainly shouldn't set the default TTL of a tethered device to 65, because then your carrier may fail apply proper limits to that traffic.

This is patently false. Source packages with Debian aren't even a single file. They consist of a pristine upstream tarball, a tarball of a /debian/ directory, and a dsc file that describes the package, including checksums of the two tarballs.

The /debian/ directory contains all distro specific patches, as well as build rules (a Make file), and package scripts.

It's possible to build a 'debian native' package where the /debian/ directory is bundled up with the orig source, but those are few and far between -- primarily packages consisting of debian-specific scripts/tools.