<samueldr>
it needs to be the first boot after a kernel crash though
<samueldr>
(IIRC)
<samueldr>
the fact it doesn't boot when flashed makes me think something must be wrong for real then, though not positive that `fastboot boot` should be expected to work
<ashkitten>
do you own a pixel xl?
<samueldr>
sadly no
<ashkitten>
alright then
<samueldr>
I wonder if it was verified as working since the gcc9 migration
<ashkitten>
for future reference, i got it by flashing twrp to the boot partition and then `fastboot boot`ing the boot image so when it crashed it'd reboot immediately into twrp
<samueldr>
good to know
<samueldr>
oh, interesting
<samueldr>
on your device the uefi stuff is in the console ramoops
<samueldr>
or uh, aboot, it looks like it's not uefi
<samueldr>
ashkitten: good news, the kernel seems to work successfully
<samueldr>
I'm not 100% positive I had it tested on hardware
<samueldr>
you may want to flash a blank file to your system partition, I think this is too big to flash on system, and instead flash this on userdata... IF YOU DO, FLASHING ON USERDATA WILL MAKE YOU LOSE ALL THE DATA IN THERE
abathur has quit [Ping timeout: 256 seconds]
<ashkitten>
ahh okay
<ashkitten>
i'll just fastboot erase system
<ashkitten>
i think that flashes a blank ext4 image?
<samueldr>
possible
<ashkitten>
oh, fastboot erase just erases it
<samueldr>
though the main issue would be you'd find yourself with two partitions with the same label, so at that point /dev/disk/by-label/... will be confused
<ashkitten>
fastboot format flashes a blank ext4 image
<samueldr>
(if you didn't erase it)
<samueldr>
good to know
<ashkitten>
what does by-label do if there's more than one partition with the same label, anyways?
<samueldr>
that I'm not sure
<samueldr>
but that's exactly what would have happened
<ashkitten>
haha
<samueldr>
hmmm, I'm thinking, since we can cross-compile a useless system image, and we have rndis, we may be able to make it so you can use the running phone over rndis as an aarch64 builder
<ashkitten>
ooh
<ashkitten>
funky bootstrap
<samueldr>
that would be dumb and good at the same time
<Church->
Heh
<Church->
Interesting
<ashkitten>
oh i should probably join #nixos-aarch64
<Church->
Probably
<samueldr>
that would be good, and more on-topic :)
<ashkitten>
heh
<ashkitten>
omg this touchpad is the worst
<ashkitten>
i need to get a legit t450s touchpad to replace this third party garbage i put inside my computer
<ashkitten>
sometimes it just randomly sends middle clicks instead of single clicks?
<clever>
ashkitten: i cant even use the tap to click on mine, due to the latency
<clever>
ashkitten: the firmware implements a tap, release, tap&hold, drag, to press left once, and drag
<clever>
ashkitten: so any time you just tap once, it doesnt know if its a drag or click, and delays sending the click
<clever>
i press control, tap, release control, then it clicks
<ashkitten>
oof
<clever>
ashkitten: i also triple left click a lot, and the firmware doesnt think thats possible, and just does wonky things
<ashkitten>
:/
<clever>
triple click with a drag on the 3rd is also a common action
<clever>
as is double with a drag on the 2nd
<samueldr>
good luck explaining that to a manufacturer
<clever>
samueldr: funnily enough, its a linux and open-source friendly vendor, system76
<samueldr>
the peeps at nexdock couldn't understand that their trackpad is basically useless since it's hardcode to simulate "windows precision touchpad" like actions with hotkeys
<clever>
samueldr: one of their most recent laptops even comes with coreboot pre-installed
<samueldr>
clever: I assumed it was
<samueldr>
yes
<samueldr>
but they're using clevo design, which in turn AFAIK touchpads are cheap ones
<clever>
samueldr: also, all of the palm detection things dont work, at all
<clever>
but there is a fn+something key, to just disable the touchpad entirely
<samueldr>
so nexdock has that neat product, but the touchpad emulates gestures sending windows-only shortcuts, when it's not expected to even be usable with windwos really :(
<ashkitten>
dammit, no network devices available
<ashkitten>
i can't post from this
<samueldr>
so I assume it booted to desktop?
<ashkitten>
yep!
<samueldr>
(it being the phone)
<samueldr>
nice!
<ashkitten>
wait hold up, i can't play minesweeper without right click
<ashkitten>
this is atrocious
<ky0ko>
ashkitten, just now: "i can't believe samueldr would send me something like this! absolute garbage!"
<samueldr>
ashkitten: the onboard keyboard has a pointer thing to allow right clicking
<ashkitten>
THANK yOAU
<samueldr>
note that there may be a bug with gtk3 based menus
<ashkitten>
yeah i noticed that
<ashkitten>
they don't work
<samueldr>
that's upstream!
<samueldr>
happens with my bog standard laptop
<samueldr>
something about touchscreen input I guess
<samueldr>
it will need to be investigated and fixed at some point, but that's not an issue with your phone or any android phone
<ashkitten>
huh
<samueldr>
it's basically all touch inputs on X11 in a similar setup
<ashkitten>
good to know
<samueldr>
on GTK3 menus*
<samueldr>
might be awesome WM though
<samueldr>
haven't tried non awesome setup
<ashkitten>
isn't this with xfce?
<samueldr>
awesome wm as the wm though
<ashkitten>
ahh
<samueldr>
imagine having to deal with xfwm with such tiny pixels :)
waleee-cl has quit [Quit: Connection closed for inactivity]
<colemickens>
What does a backing store mean in the context of a stateless NixOps?
abathur has joined #nixos-chat
* lovesegfault
screams in tensorflow
abathur has quit [Ping timeout: 264 seconds]
evanjs has quit [Ping timeout: 265 seconds]
evanjs has joined #nixos-chat
julm has quit [Ping timeout: 240 seconds]
drakonis has quit [Quit: WeeChat 2.7.1]
lovesegfault has quit [Quit: WeeChat 2.7.1]
cole-h has quit [Quit: Goodbye]
lovesegfault has joined #nixos-chat
abathur has joined #nixos-chat
lovesegfault has quit [Ping timeout: 260 seconds]
abathur has quit [Ping timeout: 265 seconds]
<ashkitten>
i realized today that android occupies a really similar place to windows in the mobile space
lovesegfault has joined #nixos-chat
<ashkitten>
it's ubiquitous, buggy, impossible to debug, and to get customization or basic functionality you're forced to resort to hacky bs from the internet
<ashkitten>
there's not even a basic text editor in android, ffs
<ashkitten>
so that's one thing windows has over it, lol
<ashkitten>
(even if notepad sucks)
<ldlework>
my andoird phone came with more than one text editing app
<ldlework>
an actual textpad and a "note" editor
<ldlework>
but they probably are not official android apps, but probably ones my provider added or something
<ldlework>
OEM shit
<ashkitten>
stock android doesn't though, and it's very hard to find something that'll just let me edit a raw text file, preferably in a monospace font
<ldlework>
nah there's gotta be something
<ldlework>
:P
<ashkitten>
it's hard to find, at least
<ashkitten>
i ended up resorting to vim inside termux
__monty__ has joined #nixos-chat
<ldlework>
hehe
<ashkitten>
i'm gonna try and get wifi working on mobile-nixos
<ashkitten>
literally i only care about having wifi and a web browser
<ldlework>
not phone service?
<ashkitten>
i can pop a sim card in a different phone for the moment
<ashkitten>
that's not important right now
<ashkitten>
i mean, hell, not like im gonna be leaving the apartment for the next month or whatever
lovesegfault has quit [Quit: WeeChat 2.7.1]
<Irenes[m]>
Fx. It's an Android filesystem browser that also has a halfway reasonable text editor.
<MichaelRaskin>
Well, if you already open F-Droid, the issue becomes moot very quickly
abathur has joined #nixos-chat
jfroche has joined #nixos-chat
abathur has quit [Ping timeout: 256 seconds]
ottidmes has joined #nixos-chat
{`-`}_ has joined #nixos-chat
{`-`} has quit [Ping timeout: 246 seconds]
abathur has joined #nixos-chat
abathur has quit [Ping timeout: 264 seconds]
jfroche has quit [Remote host closed the connection]
jfroche has joined #nixos-chat
jfroche has quit [Remote host closed the connection]
neeasade has quit [Remote host closed the connection]
abathur has joined #nixos-chat
abathur has quit [Ping timeout: 256 seconds]
abathur has joined #nixos-chat
waleee-cl has joined #nixos-chat
ottidmes has quit [Ping timeout: 240 seconds]
ottidmes has joined #nixos-chat
ottidmes has quit [Ping timeout: 256 seconds]
ottidmes has joined #nixos-chat
KeiraT has quit [Ping timeout: 240 seconds]
KeiraT has joined #nixos-chat
<eyJhb>
etu: xmodmap randomly stops working. Any idea why?
cole-h has joined #nixos-chat
<MichaelRaskin>
Replugging the keyboard might be the reason
<eyJhb>
Might happen accidentally. Any good way to run it at intervals, or something to ensure it works
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-chat
<etu>
eyJhb: I made a shellscript
<etu>
eyJhb: named fixcompose that applies my rules
<__monty__>
danderson: About the security policies for tailscale. Is there any assurance that the nodes will actually adhere to them?
<danderson>
__monty__: no. We don't assume that single nodes are trustworthy (because hello malware, or hostile insider)
<danderson>
when you define an ACL, it gets compiled and pushed to both "ends" of the connection, and both ends enforce + create audit trails for it
tilpner has quit [*.net *.split]
MichaelRaskin has quit [*.net *.split]
m1cr0man has quit [*.net *.split]
vesper11 has quit [*.net *.split]
nckx has quit [*.net *.split]
<danderson>
so if your ACL says "__monty__'s laptop can get to the accounting server", in our audit logs we expect both your laptop and the accounting server to generate an audit entry for each connection from laptop to server
nckx has joined #nixos-chat
<danderson>
if only one side generates an entry, that's a signal something's wrong - but you still have an audit trail as long as one end is uncompromised
<eyJhb>
etu: so you just rerun it when it stops working?
<danderson>
I think an early version of the website called it "double-entry accounting, but for logs"
<danderson>
every "I'm connecting out to B" log on A should be matched by an "incoming connection from A" entry on B
vesper11 has joined #nixos-chat
<danderson>
if your logs don't balance out, one of your nodes is lying, and now you know which ones to look at.
<danderson>
and at a simpler level: it means that if you run a hacked up tailscaled on your laptop, you still can't connect to stuff that the ACLs forbid
<danderson>
the packets just get dropped after riding through the wireguard tunnels
<eyJhb>
And then you teach it lying is wrong
<danderson>
instead of getting dropped early on the client
<danderson>
(and audit log discrepancies fire an alert in your SIEM, because that's a "should not happen" situation)
<danderson>
This kind of thing is why I need to write and publish a threat model for tailscale
<__monty__>
danderson: What if both nodes cooperate though? For instance, the company's policy is that employees from different offices can't connect to eachother's machines. What if Mike and Eve are in different offices but still want to connect counter to the policy?
<danderson>
most threat models start to break down when you have >1 hostile insider cooperating :)
<danderson>
in our current implementation, they could connect. But I'll point out that they could also just log into tailscale with an @evilhacker.com account, and do exactly the same thing without hacking up their tailscaled
<danderson>
once two people want their computers to communicate, it's very hard to stop them through technical mechanisms alone if they have admin on their computers
<danderson>
that said... We're planning an optimization to the key distribution logic in tailscale
<danderson>
basically: if the compiled ACLs say that no traffic is allowed to flow from A to B, we wouldn't even tell A and B about each other when we push the network map to them
<danderson>
so from A's perspective, B doesn't even exist on the tailscale network
<danderson>
but that's just an optimization. You could use the principle you describe to force an ACL wider open, if you wanted.
<danderson>
(but again, Mike and Eve could just set up a private tailscale account to do that, or run a basic wireguard tunnel, or use a socks proxy on the internet...
<danderson>
... once two people want to communicate, you're outside of the realm of "how do I stop this" and into the realm of "how do I detect this"
<danderson>
)
<gchristensen>
+1
tilpner has joined #nixos-chat
<__monty__>
You say it's easy but IME it's still unnecessarily hard to share a file between two people across the internet : )
<gchristensen>
you're just not properly and maliciously motivated
<__monty__>
Thanks for the explanation though, just kicking the tires to see if I have a basic understanding of the tech.
<danderson>
Firefox makes it ridiculously, hilariously easy to share a file
<__monty__>
Yeah, but I don't like third parties.
<danderson>
you have to round-trip it into the cloud, which is dumb, but hey
<joepie91>
transfer.sh usually works pretty well in my experience, and for P2P there's Magic Wormhole which also generally Just Works
<danderson>
same. That's why I'm trying to fix that with tailscale :)
<__monty__>
And I don't like the ephemerality either tbh.
<joepie91>
though I think that is opportunistic P2P
<danderson>
p2p apps should be trivial to build. But they're not, because of the connectivity and identity problems
<srk>
__monty__: internet is broken due to all teh NATs
<danderson>
and <danger, shilling ahead>, I think tailscale has a good chance of solving those problems well
<__monty__>
joepie91: Yeah, transfer's great as a "pastebin for any file type."
<danderson>
(but obviously I think that, I work at tailscale, so clearly I believe in our premise)
<danderson>
and yes, NAT broke the internet
<__monty__>
joepie91: And magic-wormhole's cool tech. Though I like "croc" because it's *so* easy for low-tech people to work with. Though it doesn't do even opportunistic p2p, always goes through the relay.
<danderson>
I'm going to write an article about NAT traversal techniques for tailscale's blog. I'm tempted to start it with something like "NAT is the reason we don't have the cyberpunk future internet I was promised in the 90s"
<joepie91>
danderson: so what's the deal with tailscale licensing-wise? because I see "open-source" mentioned consistently in a very carefully-worded context, "open-source node software", which suggests that there is a proprietary component to it
<__monty__>
Have you looked at toxvpn? It's what I use currently for my personal machines. I wonder how trivial replicating that setup with tailscale would be?
<danderson>
NAT is the single greatest gravitational pull towards cloud platforms. With NAT, cloud becomes indispensable, and the only way to build anything significant
<danderson>
and I hate that :)
<danderson>
joepie91: good eye! There's two major pieces to tailscale: the node agent that handles meshing of your nodes together and p2p traffic
<joepie91>
mm, NAT is one part of the puzzle, but IMO the complexity of distributed systems is a bigger issue
<joepie91>
especially trustless ones
<danderson>
and the control plane, which ties node pubkeys to external OAuth identities, and acts as a key dropbox for nodes to find each other
<danderson>
currently, the core of node software is open source (github.com/tailscale/tailscale)
<danderson>
if you run linux or *bsd, that repo contains all of the code you're running.
<danderson>
the macOS and iOS clients use the same core network engine, but have a proprietary GUI and glue on top of it.
<danderson>
in part because frankly, a fancy GUI is the bit a competitor would most likely clone to compete with us.
<danderson>
and in other part because we have to use apple's NetworkExtension framework to run as a VPN app
<danderson>
and being a NetworkExtension requires a fancy developer certificate + entitlement from Apple
<danderson>
so it's kinda pointless to distribute it, because you can't even compile it without that cert
<danderson>
as in, xcode immediately tells you to get lost because you're trying to compile a NetworkExtension and apple hasn't authorized you to do that
<danderson>
and the control plane is proprietary, because that's where a lot of the enterprise value-add is (centralized ACLs, audit logs, "single pane of glass" monitoring...), and we have to make money somehow.
<__monty__>
You can't override that to run it on your own hardware only even?
<danderson>
__monty__: nope!
<danderson>
NetworkExtension == pay apple $100, then beg them for an entitlement to build NetworkExtensions
<danderson>
Technically on macOS, we can use utun instead of NetworkExtension, which would let us build the OSS tailscaled and run that without the xcode dependency
<danderson>
but if you want to be in the Mac Store, you have to use NetworkExtension if you're a VPN app.
<danderson>
anyway, back to the original question: no, tailscale is not 100% open source.
<danderson>
and the bits that are not open are 100% driven by "sorry, under capitalism we have to make money somehow, and we can't do that if enterprises can just run the whole thing for free" :(
<danderson>
so, if that's a deal breaker, then sorry, and thanks for checking us out :)
<danderson>
that said, we're all open source enthusiasts, so we're trying to open source as much as we can without giving away profitability. And we want to have a free (gratis) tier that is suitable for non-companies for ever.
<danderson>
(selfishly, because I want to use tailscale and I don't like paying for software ;) )
<__monty__>
danderson: Have you checked out toxvpn?
<danderson>
not recently. At a quick glance, it seems similar at a base level to what tailscale does, albeit without the extra niceties we're adding
<danderson>
(e.g. I don't see nat traversal, it seems to roll its own crypto in C++ which I personally find dicey, and it looks like it depends on some bittorrent-ey DHT as a control plane, which a bunch of networks might block?)
neeasade has joined #nixos-chat
<danderson>
but I'd have to dig much deeper into the code to have a more informed opinion
<__monty__>
What I'm looking for mostly is info in how easy setup is in comparison. Toxvpn sets up a subnet(?) so I just get an IP for every node as if they're on a LAN of their own.
<danderson>
that's exactly what tailscale does as well.
<danderson>
from your machine's perspective, you're on a virtual LAN with your other machines.
<danderson>
(except it's more of a "smart network fabric", because we can do stuff like ACL enforcement and audit logging, even though the illusion is one flat network)
<danderson>
in the same space, other things you might want to check out are tinc and zerotier
<danderson>
zerotier is less libre than tailscale (BSL), and has different design principles that make it better at some stuff and worse at others
<danderson>
but it's a good system
<danderson>
tinc... I remember looking at it and thinking "eh, s'fine", but not details, sorry
wildtrees has joined #nixos-chat
<__monty__>
Tinc is interesting but doesn't have the component I really need. Connecting devices behind NAT on both sides.
<danderson>
Oh? It advertises NAT traversal, I assumed that's what it was
<danderson>
robust NAT traversal really is the key to a solid mesh VPN offering. Nobody does it very well yet (including tailscale - there's a lot I want to do to our magicsock implementation)
<danderson>
that's the main expertise I bring to tailscale - I've spent a decade breaking my brain on NAT traversal :)
<danderson>
(also building software-defined networks and robust systems in general, but...)
<__monty__>
Well tinc does it but only if you have a node in the mesh that's reachable from the nodes behind NAT afaik.
<__monty__>
An issue tailscale sidesteps by offering that reachable node.
<danderson>
ah, I see
<danderson>
yes, fundamentally for NAT traversal you _need_ a globally visible coordinator to help peers traverse NATs
<danderson>
you can break through simple setups without it, but nothing actually interesting.
<danderson>
specifically, modern NAT traversal techniques require two peers to have a low-bandwidth side channel to exchange metadata and iterate on connectivity
<__monty__>
I've always wondered why a DHT can't serve that role.
<danderson>
If you're curious, you can read the ICE RFC, that's the state of the art for NAT traversal
<danderson>
can a DHT give you interactive message exchange?
<danderson>
I think of it as a key/value store, not as "I send you a message and you receive it quickly"
<danderson>
I mean, no reason it can't in theory, but I don't know if existing DHTs on the internet do that
<__monty__>
Depends on your definition of quick I guess.
<danderson>
well, you need multiple back-and-forth message exchanges to pierce through most NATs.
<danderson>
the slower those messages, the slower the connection establishment
<danderson>
and beyond a certain point, it's slow enough that the connection establishment just fails.
<danderson>
so, call it <5s to deliver 1 message, if you're okay with connection setup taking 10-20s
<__monty__>
Well I assumed you could keep a route open on your side, advertise it in a DHT and then another node that does the same thing can simply use that info to connect?
<danderson>
define "keep a route open" ?
<__monty__>
A port on your router I guess.
<danderson>
most modern NATs require bidirectional traffic to make a mapping stick
<danderson>
so you really need the two peers to be trying to talk to each other simultaneously
<danderson>
I'm not going to go into the details here because it'll take me a couple hours and I need to actually get work done :)
<danderson>
but tl;dr: the closer you can get to instant communication between the peers on the side channel, the better your chances of piercing the NATs
<__monty__>
Ah, I thought if you kept sending packets the same port'd stay open.
<danderson>
and for some advanced techniques, you need really interactive chatter, like "okay now try this", "nope that didn't work, trying this..."
<danderson>
it depends. That's true for maybe 90% of NAT boxes out there
<danderson>
so if your goal is "I can connect 90% of the time", that's really easy :)
<danderson>
if your goal is 100% of the time... Well that's impossible because some networks just block too much traffic and you _must_ use a relay machine
<__monty__>
Do most (managed) home routers fit that category?
<danderson>
if your goal is 99% connectivity, that 90% -> 99% is really tough to achieve
<danderson>
90% of home routers do ;)
<danderson>
OEMs ship _really_ broken routers, when you start digging into their NAT behavior.
<danderson>
one of my teammates has an ISP-provided home router that has an amazing behavior
<danderson>
picture 2 LAN clients, running tailscale on their local port 41641.
<danderson>
first one sends a packet to the internet. The router allocates port 41641 on the public IP to that client.
<__monty__>
Ok, thanks for the info. The ICE and STUN stuff is definitely on my reading list, just have at least 700 more pages to get through before I can shift focus again : )
<danderson>
so far, so good.
<danderson>
then client 2 sends a packet as well. Router *throws away* the previous 41641 mapping, and reallocates 41641 to the 2nd client
<danderson>
so now your previously working client 1 just... stops getting traffic.
<danderson>
and client 2 starts getting random noise of packets that were meant for client 1
<danderson>
in NAT parlance, that's called a "port overriding" NAT box
<danderson>
it's been widely documented to be a catastrophically bad idea for over a decade, and that no NAT box should do this, ever
<__monty__>
I guess that *is* the simplest implementation >.<
<danderson>
not only because it makes NAT traversal hard, but because it just breaks normal clients *all the time*
<danderson>
and yes, this is what his ISP provides as a home router, in 2020 :(
<__monty__>
Wouldn't it create similar trouble as soon as two clients in the LAN try to reach an HTTP website? Or HTTPS with the same port?
<danderson>
the mapping is based on the LAN client's source port
<danderson>
which is usually random
<__monty__>
Oh, right.
<danderson>
so you have about 1/40000 chance of a collision
<danderson>
but with enough clients, or enough time... Yeah, it breaks shit all the time
<danderson>
but it just manifests as "hmm this website seems to be timing out"
<danderson>
so people just go "bleh the internet is broken", reboot the router, and the problem goes away
<danderson>
and that's how you train people that "the internet" is unreliable :(
<danderson>
we hit this frequently with tailscale, because we pin tailscaled to port 41641 by default
<danderson>
(a concession to enterprises, so that they can tag that UDP port as tailscale traffic in their SIEM)
<danderson>
so as soon as you have 2 tailscale daemons running behind one of those routers... One of them will consistently fail to talk to anything on the internet over UDP
<danderson>
and the other will start to get random backscatter garbage packets that were meant for the other client
<danderson>
*that* kind of thing is the nightmare long tail of NAT traversal :)
<danderson>
90% connectivity is trivial. 99% connectivity... You have to deal with broken NAT boxes, buggy kernels (ask me someday about the kernel bug I'm tracking down in linux 4.19's NAT implementation)
<__monty__>
inb4 companies using routers running into this same issue... : )
MichaelRaskin has joined #nixos-chat
<danderson>
and basically that's why tailscale runs a network of DERP relays. For all those broken cases, we give you a fallback where you can relay your packets through an HTTPS proxy, because that has a good chance of always working
<danderson>
(because ISPs don't usually break HTTP/HTTPS too badly, because that makes customers complain)
<danderson>
the challenge with DERP is that it costs us money to forward your packets, and it hides legitimate bugs in our NAT traversal logic.
<danderson>
so we need great logging to figure out that hey, we _should_ have succeeded at traversing your NAT, but instead we're running your traffic over DERP, that's not right
<danderson>
but from your POV, that's still 100% successful connectivity :)
* tilpner
can confirm that tinc can directly connect two devices behind NAT
<danderson>
in a way, learning about NAT traversal is a zen experience. You learn to strive for perfection, while accepting that it's unattainable
<__monty__>
tilpner: But you have a node in the mesh that's reachable from those devices, right?
<tilpner>
Yes, but you have that everywhere
<__monty__>
You do?
<tilpner>
Where don't you?
<danderson>
does tinc run a coordination server for you?
<tilpner>
No, I have a 3€/month VPS with Hetzner Cloud for that
<tilpner>
(Which also doubles as a port-forwarder via wireguard)
<danderson>
okay, so you have to run your own globally reachable server
<danderson>
but once you have that, can 2 nodes behind NATs establish a p2p link?
<danderson>
or do they relay via the server?
<tilpner>
They relay at first, but directly connect after a while
<danderson>
ok, so yeah, it does do some kind of nat traversal, at least a basic form
<danderson>
(probably a custom variant of ICE)
<cole-h>
danderson++ Despite the fact that I know nothing about this domain, I find your information really interesting to read.
<{^_^}>
danderson's karma got increased to 5
<danderson>
The great thing is I get to rant about all this stuff because none of it's secret, it's just really hard to get right
<danderson>
so there's no competitive risk to tailscale :P
<danderson>
(in the sense that there's no secret sauce, just a long tail of well-known but really fiddly stuff you have to implement)
<cransom>
i just enjoy that it's not cisco/juniper/et al introducing something halfly baked that you then also have to incorporate hardware for with pita licensing.
<danderson>
Ah well let me tell you about the Tailscale TS960 with additional cryptographic linecards and per-cipher licensing!
<danderson>
(no, not really - but I've been scarred by invoices from juniper before :) )
<cransom>
my wounds are not from invoices, but from the hardware itself. srx has taken a couple years off my life, i'm sure.
<danderson>
heh
<danderson>
I remember the SRX100. That was a box that should not have existed
<danderson>
there is a lower limit to how much CPU performance and RAM you can take away before JunOS just stops working
<danderson>
and the SRX100 is proof of that :)
<cransom>
i had one. it was... just ok. i'm not sure it was any slower than the srx3ks in terms of boot and time to doing something useful.
<danderson>
the only big iron junipers I got to play with were already booted by the time I got to touch them, so I dunno :)
<danderson>
biggest I ever got to run commands on was an MX2020, 700kg of badass
<danderson>
(and also $800k to purchase with all the linecards and stuff, ouch)
drakonis has joined #nixos-chat
abathur has quit [Ping timeout: 256 seconds]
<gchristensen>
complicated rebases are complicated :(
<__monty__>
amen
abathur has joined #nixos-chat
<etu>
eyJhb: Yep :D
lovesegfault has joined #nixos-chat
pie_[bnc] has quit [Quit: No Ping reply in 180 seconds.]
<cole-h>
Are there any decent GTK MPD clients out there?
<srk>
sonata is nice
pie_[bnc] has joined #nixos-chat
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-chat
__monty__ has quit [Quit: leaving]
tokudan has quit [Remote host closed the connection]