<mithro>
We do 720p30 over USB2.0 -- we are working on porting the Daisho USB3.0 core to the Xilinx GTPs (we already have it working on the Xilinx board with an external USB PHY)
<cyrozap>
rqou: Oh, hm, for some reason I thought he was also reversing the 802.11 MAC code, but I could be mistaken.
<rqou>
i mostly see lwip and rtos/peripheral stuff
<rqou>
which is arguably much more useful, but not the part i care about
* awygle
tries very hard not to wonder if he could make an open Wi-Fi radio
<azonenberg_work>
inb4 802.11 sdr bitbang
<awygle>
azonenberg_work: that was _your_ idea, you know :-P
<azonenberg_work>
Lol
<azonenberg_work>
no if you want to be really crazy
<azonenberg_work>
Make a PWM DAC
<azonenberg_work>
with one of those 32 Gbps UltraScale transceivers
<azonenberg_work>
how many bits at 2.4 Gsps is that? :p
<lain>
cnlohr on youtube did ntsc broadcast bitbang on an esp8266 (or was it a esp32?)
<azonenberg_work>
lain: cnlohr did 10baseT bitbang on an attiny
<lain>
esp -> piece of wire -> analog tv across the room
<lain>
that too
<azonenberg_work>
That was the inspiration for tragiclaser
<azonenberg_work>
Back at RPI, alex rad and a few other folks from the eclub did something great for the nyu poly embedded security contest
<azonenberg_work>
They had a board with a VGA monitor on it
<azonenberg_work>
They modulated the blue channel of the VGA signal at like 16 kHz
<azonenberg_work>
using the entire VGA cable as an antenna
<azonenberg_work>
and exfiltrated the key
<lain>
lol
<azonenberg_work>
The receiver was a pair of headphones with one speaker wire broken (so a piece of wire feeding into a headphone jack)
<azonenberg_work>
digitized with a sound card
<azonenberg_work>
and demodulated in software
<azonenberg_work>
i forget the modulation, i think BFSK?
<awygle>
azonenberg_work: only like 14 bits
<azonenberg_work>
awygle: 14 bits with 32 Gbps -> 2.4 Gsps?
<azonenberg_work>
Yeah that sounds right
<azonenberg_work>
closer to 13 i think
<azonenberg_work>
is that enough?
<azonenberg_work>
i guess the bigger issue is
<awygle>
Yeah I bumped it to 48 for some reason
<azonenberg_work>
you cant bitbang wifi with 2.4 Gsps
<azonenberg_work>
you'd need faster
<azonenberg_work>
or, alternatively
<azonenberg_work>
actually better idea
<awygle>
O boi
<azonenberg_work>
How about you have a normal GTP running a 4.8 Gbps squarewave
<azonenberg_work>
To produce the carrier
<awygle>
Oh that's much more sensible
<azonenberg_work>
i.e. 0x5555
<azonenberg_work>
Use some RC filters to remove harmonics and turn it into a 2.4 GHz sinusoid
<azonenberg_work>
Then use a PWM DAC at say 1 GHz on a normal GPIO
<azonenberg_work>
to get say 8 bits at 125 Msps (if my mental math is right)
<azonenberg_work>
for the baseband I/Q data
<azonenberg_work>
Then use a couple of discrete transistors or even (kinda cheating?) an RF mixer IC
<azonenberg_work>
to mix with the GTP-generated carrier
<awygle>
You'd need like 5 Gbps to get 8 bits at 20 MHz, right?
<azonenberg_work>
oh wait
<azonenberg_work>
yeah i divided wrong :p
<awygle>
Pretty sure at 125M you only get 3
<azonenberg_work>
Fine, use another GTP
<azonenberg_work>
One for the carrier and one for I and Q
<azonenberg_work>
Alternatively, use a bunch of normal GPIOs and a resistor string
<awygle>
Definitely
<azonenberg_work>
like the cheap VGA stuff does
<azonenberg_work>
That is probably easier
<azonenberg_work>
In any case the RX would be the hard part
<awygle>
Always is
<azonenberg_work>
But...
<rqou>
how about start out with doing it correctly? :P
<azonenberg_work>
Lol
<azonenberg_work>
Ok fine, ADC + DAC + rf mixers?
<rqou>
(i don't understand enough of the math for how to build a wifi phy)
<awygle>
How fine of phase control can you get on a GTP?
<azonenberg_work>
awygle: Not fine enough
<azonenberg_work>
They're digital PHYs
<azonenberg_work>
they're not meant for this kind of abuse lol
<awygle>
They do clock recovery and PLL and stuff though right? Seems like phase should be doable for a Costas loop or something
<azonenberg_work>
they do but you dont have much visibility or control
<azonenberg_work>
it automagically happens
<awygle>
(but yes adc+dac+fet mixer+amp is better)
<rqou>
somebody teach me the math behind wifi phys pl0x?
* azonenberg_work
hides behind an RJ45
<azonenberg_work>
and tries to look small
<azonenberg_work>
scary math!
<awygle>
rqou: first you have DBPSK, then you have DQPSK, then *mumblemumble* and you can get 300 Mbps!
<awygle>
Wi-Fi is one of those things where the individual parts aren't actually that hard/scary but the whole thing together becomes a nightmare
<cr1901_modern>
>"They do clock recovery and PLL and stuff though right?"
<cr1901_modern>
>They're digital PHYs
<cr1901_modern>
I would not trust an ADPLL for high speed
<awygle>
I assume the clock recovery magic is analog?
<cr1901_modern>
I don't know why you make a distinction between clock recovery and PLL, tbh
<awygle>
cr1901_modern: because there's more to clock recovery than just a PLL, often
<cr1901_modern>
In any case, if it's a purely digital PHY your phase control is going to suck/be limited to fractions of a full (reference) cycle
<azonenberg_work>
Yes exactly
<cr1901_modern>
awygle: There is? I thought it was just a PLL tuned to "remember its previous freq in the absence of transitions"
<awygle>
cr1901_modern: depends how complicated you get. The only one I know well is a Costas loop. Also you used to have to do phase detection (usually with a preamble) before we invented XbYb coding
<awygle>
Iirc there are other methods too. Mueller and Muller
<cr1901_modern>
I only know Costas loop as a DSB AM decoder (and don't remember how it works)
<awygle>
Wireless is complicated, you have to recover the carrier clock and the data clock
<awygle>
I am not actually that good at dsp tho so I'll stop talking now
<cr1901_modern>
azonenberg_work: So actually, I'm not sure why "jitter is bad" at high speeds, even with a digital PHY. I just know it is.
<cr1901_modern>
Are there other reasons beyond "the recovered clock may come too late/too early and cause setup/hold time violations"?
<azonenberg_work>
cr1901_modern: thats the main thing
<azonenberg_work>
awygle: You dont have to do the carrier clock if you do I/Q decoding
<azonenberg_work>
A static phase offset between the TX and RX carriers just rotates the constellation, you can correct with a couple known symbols at the start of a packet
<awygle>
azonenberg_work: I know, I just don't remember how to do that off the top of my head
<azonenberg_work>
A different in carrier rate turns the constellation into a spiral
<azonenberg_work>
rather then N straight lines going down the time axis
<azonenberg_work>
So you just measure the rotational offset from one symbol to the next relative to your ideal
<azonenberg_work>
and apply an inverse rotation to recenter
<awygle>
I was thinking of IQ mixing for some reason
<cyrozap>
azonenberg_work: You don't even need known preamble symbols if you use differential coding--you "just" need to square and equalize the constellation (because you don't need the absolute phase offset) and you're good to go. That's what ClearQAM (ITU-T J.83b) does, anyways.
<awygle>
cyrozap: you lose 3db Eb/No though iirc
<awygle>
Yeah, it basically doubles your BER at a given SNR because one error is two errors
<azonenberg_work>
Yeah i would rather go with a non-differential code and a preamble
<azonenberg_work>
For better noise resilience
<azonenberg_work>
Actually speaking of whih
<azonenberg_work>
You know what would be cool?
<azonenberg_work>
Bitbang DOCSIS
<azonenberg_work>
Open source cable modem :D
<awygle>
How does docsis even work?
<azonenberg_work>
I know its high order QAM
<azonenberg_work>
like 1024 constellation points or something absurd
<azonenberg_work>
But i dont know more than that
<awygle>
Oh holy shit 16384-QAM? You're not bitbanging that
<azonenberg_work>
16K?
<azonenberg_work>
lol
<awygle>
That's the upper limit but yeah
<azonenberg_work>
Depends on if you consider a DAC bitbanging
<azonenberg_work>
With a good dac you could totally SDR it
<awygle>
It's only 6.4 MHz channels
<awygle>
You don't even need that good of a DAC/ADC
<awygle>
Just lots of DSP horsepower
<awygle>
Oh wait those are subcarriers, 192 MHz total channel
<cyrozap>
azonenberg_work: The problem with open source cable modems is that it's illegal to connect them to a cable company's network without explicit permission, so you'd have to build your own network for testing.
<awygle>
For 3.0. 2.0 looks much much easier
<gruetzkopf>
DVB-C2 (for cable broadcast TV ) even defines 65536-point QAM, but their objective was to never have to touch it again
<awygle>
cyrozap: really? I know you need a DOCSIS rool cert basically, then you just give your MAC to the cable company right?
<gruetzkopf>
and i've been trying to get a CMTS (docsis headend) for a while, unsuccessfuly
<cyrozap>
awygle: 3.0 is basically just multi-channel 2.0. A lot of the improvements in 3.0 are in higher layers of the stack.
<awygle>
cyrozap: I guess 3.1 is really what added the crazy QAM levels according to Wikipedia
<cyrozap>
awygle: 3.1 uses OFDM, it's basically a new phy standard.
<awygle>
Well if anybody wants to give it a try let me know, it sounds like fun lol
<cyrozap>
"(1) No person shall intercept or receive or assist in intercepting or receiving any communications service offered over a cable system, unless specifically authorized to do so by a cable operator or as may otherwise be specifically authorized by law."
<cyrozap>
"(2) For the purpose of this section, the term “assist in intercepting or receiving” shall include the manufacture or distribution of equipment intended by the manufacturer or distributor (as the case may be) for unauthorized reception of any communications service offered over a cable system in violation of subparagraph (1)."
<awygle>
OK I get what you were saying now
<cyrozap>
The law was written to combat cable TV service theft back before content scrambling was a thing.
<awygle>
It costs something like a quarter million dollars to certify a DOCSIS 3.1 modem apparently
<cyrozap>
Then it was used to combat theft of internet service in the time before BPI/BPI+/SEC was added to DOCSIS, and even afterwards.
<cyrozap>
Oh, wow.
<cyrozap>
Also, even if you get the modem certified by Cable Labs, you can't use it with a cable ISP until they also certify it for use on their network.
<awygle>
Unsurprising
<awygle>
Maybe go at it from the other side. Build a CMTS first/instead
<cyrozap>
And if you don't get it certified by both before connecting it to the cable system, it's technically a federal crime.
<cyrozap>
Yeah, you need to build/buy a CMTS first.
<cyrozap>
It would probably be (legally) easier to build and sell an open source CMTS than a cable modem, since the cheapest DOCSIS 3.0 CMTSes I've seen on ebay are ~$9000.
<cyrozap>
With the proliferation of SDRs with high TX/RX bandwidths, you might not even have to design your own PCBs.
<awygle>
Yeah. Build the CMTS, then you can say "look we don't certify that these modems are DOCSIS compliant but they'll work with our CMTS"
<cyrozap>
Oh, I was just thinking of building and selling the CMTS and skipping the cable modem, because the cable companies are not going to want their users to have full control over their modems.
<awygle>
I was thinking of building the CMTS, building a network on it, and having open modems that connect to that network
<cr1901_modern>
The books on analog PLLs (read sinusoidal output) I've read discuss jitter as being undesirable b/c distortion when modulating/demodulating,etc.
<awygle>
The middle part being the hardest of course
<cr1901_modern>
In digital systems, jitter isn't as dire at lower frequencies, but becomes a huge deal at higher frequencies b/c "less time to get things done before next clock tick".
<cr1901_modern>
I wonder if a similar principle in the analog domain applies as you scale frequency up
<cr1901_modern>
B/c I haven't seen any literature to suggest that jitter gets more dire in the analog domain w/ higher freqs (just that it's bad period :P)
<awygle>
I would expect jitter to be an issue for PLL bandwidth as well. Your PLL may lose lock.
<cyrozap>
awygle: That sounds like something that'd be cool to have at a place like CCC. I know they do super serious networking stuff at those events.
<cr1901_modern>
that's why you have a low loop bandwidth... reduce said jitter
<cr1901_modern>
Not that I understand the math, but see Chapter 3 of Gardner's Phaselock Techniques. Should be first result on Google.
<awygle>
cr1901_modern: my understanding is that low bandwidth will reduce output jitter but increase susceptibility to input jitter causing you to lose lock. I could be wrong tho
<cr1901_modern>
That... doesn't sound right to me
<cyrozap>
awygle: Also, the hard part in building a DOCSIS modem is in the software stack, not so much the hardware, because as I said you can buy off-the-shelf TV tuners to do the downstream channel decoding, and then you only need a basic TX-only SDR to handle upstream comms.
<awygle>
cyrozap: ofdm is nontrivial if you wanted to do 3.1
<awygle>
Even bonded channels I'd expect to add nonzero complexity
<awygle>
But yes, I take your point
<cyrozap>
awygle: Yeah, I was only talking about 3.0 and earlier.
<awygle>
They're incentivized to make the hardware cheap and the software complex for reasons of marginal cost
<awygle>
Also it depends on whether you count all the TDMA/S-CDMA stuff as hardware or software lol
<awygle>
Legally speaking the advantage of doing cable stuff instead of wireless is you don't need a spectrum allocation
<cyrozap>
Bonded channels are easy, because they're separate MPEG-2 transport streams, so you just need to de-multiplex the packets.
<cyrozap>
Well, once you're using cables, you may as well just use Ethernet :P
<cyrozap>
Or fiber.
<awygle>
Good luck time sharing Ethernet
<cyrozap>
Ethernet switches exist...
<awygle>
I don't know anything about the fibery bits
<rqou>
latex sucks, news at 11
<rqou>
mathjax is really neat though
ZipCPU|Laptop has quit [Quit: Transitioning to a lower energy state]
<azonenberg_work>
awygle: or you could just do ham if you wanted to do radio
<azonenberg_work>
or an ISM band
<azonenberg_work>
at some point i want to play with both OFDM and radar in the 5 GHz band
<azonenberg_work>
Unsure if under ham or ism rules at this time
<rqou>
fortunately ham overlaps ism on both 2.4ghz and 5ghz
<rqou>
(but not completely, make sure you check)
<azonenberg_work>
i know, thats why i mentioned :p
<azonenberg_work>
awygle: as far as fiber ethernet, i know the physical layer for gigabit well as i've implemented it
<azonenberg_work>
You basically take each byte in on the GMII interface
<rqou>
you can also do gsm on one of the EU bands :P
<azonenberg_work>
8b10b code
<azonenberg_work>
and serialize it out on th efiber
<azonenberg_work>
then you send 8b10b control codes to indicate start/end of frame, error, and idle
<azonenberg_work>
iirc 100baseFX is basically the line code for 100baseT but sent at 125 Mbps to a fiber instead of to the MLT-3 coder
<azonenberg_work>
10Gbase-R is 64/66b coded XGMII data
<azonenberg_work>
also with control codes inserted but i forget the specifics
<azonenberg_work>
awygle: and time sharing ethernet? nobody's been doing that since the days of 10/half
<azonenberg_work>
Despite the standard still calling it CSMA/CD :p
user10032 has quit [Remote host closed the connection]
<azonenberg_work>
Seriously we have switches for a reason
<azonenberg_work>
cyrozap: its still illegal to sell a scanner in the us that has analog cellular bands on it
<azonenberg_work>
How many years has it been since those networks were shut down? :p
<azonenberg_work>
on a related note, given that 18 usc 2511 exists, that statute appears redundant
<awygle>
azonenberg_work: switches cost more than TDMA was my point. There's a reason they don't use Ethernet to houses (although it's mostly that the wires exist I'd guess)
<azonenberg_work>
The reason they dont use ethernet to houses is because of the cost of the cable plant
<azonenberg_work>
Nobody wants to run long haul point to point wires
<awygle>
Mhm
soylentyellow has joined ##openfpga
<cyrozap>
DOCSIS was invented because cable companies wanted to compete with the phone (DSL) companies for internet service, and they wanted to use the existing lines and supporting equipment to do so.
<azonenberg_work>
Exactky
<azonenberg_work>
IMO if we were deploying internet services new today
<azonenberg_work>
we'd have 10G fibers on the poles between houses
<azonenberg_work>
Switches on poles every couple of houses with 1G direct fibers going out to each house, capped at the switch to whatever service class you were paying for
<rqou>
yeah, china is deployed this way
<rqou>
except it might be PON
<azonenberg_work>
Then the 10G fiber from each street/neighborhood would run to larger multi-port switches every couple of blocks
<azonenberg_work>
with say a 100G backhaul to the ISP core network
<azonenberg_work>
maybe over WDM to save costs on long-haul cabling
<azonenberg_work>
Depending on how close the access-layer switches were to consumer houses they could potentially run multimode from the poles to the houses
<azonenberg_work>
then singlemode only for the access-to-neighborhood and neighborhood-to-core routes
<azonenberg_work>
now the consumer CPE can simply be a media converter
<azonenberg_work>
1G SFP on one side, copper PHY on the other
<azonenberg_work>
totally layer 2
<azonenberg_work>
Businesses wont even need a CPE, just buy a SFP and stick it in their border router
<azonenberg_work>
The consumer CPE would cost like $5-10 plus the PSU and SFP
<azonenberg_work>
I say this because i know the exact microsemi chip you'd want to bridge from 1000base-X to GMII then you just throw a PHY and RJ45 in there
<azonenberg_work>
then guesstimate a bit for enclosure, assembly costs, volume discount, etc
<cyrozap>
azonenberg_work: Uh, you still need authentication and encryption to the core network. Otherwise, you'll have people climbing telephone poles to plug in their own fiber, people splicing others' fibers to either get service or spy on them, etc. So you'd still need some kind of "smart" CPE.
<azonenberg_work>
cyrozap: 802.1x works fine everywhere else
<azonenberg_work>
the access layer would be entirely passive layer 2 switching
<azonenberg_work>
With auth done at the connection to the core
<azonenberg_work>
The average service thief is unlikely to be able to splice fiber successfully
<azonenberg_work>
if you want to go extreme enough run IPSec tunnels from every user back to the core network
<azonenberg_work>
Require a client cert to auth, encrypt all traffic to the back end
<cyrozap>
azonenberg_work: That doesn't provide encryption, though, and passes a lot more information in the clear during authN than I'm comfortable with.
<azonenberg_work>
then go cleartext when you hit the core network
<azonenberg_work>
cyrozap: IMO if you rely on your traffic being confidential once it hits the pole on the street
<azonenberg_work>
You're doing it wrong
<azonenberg_work>
TLS end to end and treat the ISP as compromised
<azonenberg_work>
Any threat model that trusts the ISP access layer or core network will fail
<cyrozap>
azonenberg_work: Right, this is just to prevent neighbors from spying on each other.
<azonenberg_work>
And if you TLS end to end
<azonenberg_work>
neighbors cannot spy on each other
<azonenberg_work>
Problem solved
<azonenberg_work>
Deploying ISP-to-user VPN would simply be a crutch until we kill off cleartext HTTP entirely
<azonenberg_work>
and reassign port 80 to some not-yet-invented protocol
<cyrozap>
Neighbors could still see and possibly tamper with DNS requests, and they can sniff the SNI from the TLS exchange.
<azonenberg_work>
Once packets leave your computer, or certainly your border router
<azonenberg_work>
They should be considered public information
<azonenberg_work>
if you are not happy with this, your protocol is leaky and needs to be fixed
<cyrozap>
This isn't about protecting just me, it's about protecting random normal people, and they don't always get to choose what protocols they use to interact with services.
digshadow has quit [Ping timeout: 268 seconds]
<azonenberg_work>
No but if you obsolete the leaky protocols
<azonenberg_work>
nobody can get hurt by using them
<azonenberg_work>
As a short term solution, as i mentioned earlier, you can run a VPN over the ethernet
<cyrozap>
I honestly wish you good luck with that :P
<azonenberg_work>
This solves the user-to-ISP auth problem as well as user-to-user confidentiality
<azonenberg_work>
user-to-ISP confidentiality is a lost cause and has always been, the only solution is 100% TLS
<azonenberg_work>
and as you mentoined even that wont stop domain name leaks via SNI and DNS
<azonenberg_work>
Tampering with DNS is a non-issue if everyone uses TLS
<azonenberg_work>
the most you could do is DoS
<azonenberg_work>
since certs would fail to verify
<azonenberg_work>
ditto for arp spoofing etc
<azonenberg_work>
incidentally this is why i agree with a bunch of other folks that dnssec is stupid and a waste of time
<azonenberg_work>
If you run end to end TLS an attacker on the network can:
<cyrozap>
Yes, of course the perfect solution is to end-to-end encrypt everything, but the world isn't built on perfect solutions, which is why we need defense in depth.
<azonenberg_work>
drop packets (DoS)
soylentyellow has quit [Read error: Connection timed out]
<azonenberg_work>
alter / misroute packets (DoS as a result of MAC failures)
<azonenberg_work>
MITM by tampering with IP headers or DNS requests (DoS as a result of certificate failure)
<azonenberg_work>
or pass your traffic unmodified (they only see ciphertext, your connection works)
<azonenberg_work>
So what problem does authenticating DNS solve exactly?
<azonenberg_work>
tampering with signed DNS queries simply shifts the DoS to tampering a different packet
<cyrozap>
I never suggested using DNSSEC
soylentyellow has joined ##openfpga
<azonenberg_work>
Yeah i know but you mentioned dns earlier
<cyrozap>
I just don't want a regression in functionality when we switch to the Network of the Future™
<azonenberg_work>
If you really think that you can't solve this problem with existing LAN techniques
<cyrozap>
DOCSIS has encryption to the CMTS
<azonenberg_work>
Like port security and 802.1x
<azonenberg_work>
Then run IPSEC to the ISP next-hop router
<azonenberg_work>
Problem solved
<cyrozap>
Yeah
<azonenberg_work>
Now you have the same level of confidentiality as docsis but running IEEE/IETF standard protocols
<cyrozap>
...so as I was saying, you'd still need a CPE for consumers who don't know wtf IPsec is or who don't have a router that supports it and has hardware encryption.
<azonenberg_work>
Or you could just ensure makers of commodity wifi APs etc provide SFP ports and add ipsec drivers
<cyrozap>
> commodity wifi APs
<cyrozap>
> SFP ports
<cyrozap>
*my sides*
<cyrozap>
azonenberg_work: You'd have an easier time getting a herd of cats to herd a second, larger herd of cats.
<azonenberg_work>
I dont need more shirts but this is funny :p
* azonenberg_work
imagines looking up in the sky and seeing a QAM-16 constellation floating there
azonenberg_work has quit [Ping timeout: 248 seconds]
user10032 has joined ##openfpga
_whitelogger has joined ##openfpga
carl0s has joined ##openfpga
azonenberg_work has joined ##openfpga
m_t has joined ##openfpga
xdeller_ has joined ##openfpga
xdeller has quit [Ping timeout: 246 seconds]
azonenberg_work has quit [Ping timeout: 248 seconds]
sgstair has quit [Remote host closed the connection]
sgstair has joined ##openfpga
<pie_>
man this puerto rico debacle is fucked up, i specifically havent been paying attention to it but something something new orleans? anyway, america would have had a chance to look good for once.
<qu1j0t3>
looking good has dropped down the priority list
<rqou>
wait, so this clip is actually from _earlier this week_?!
<rqou>
the trashfire is bigger than expected
teepee has joined ##openfpga
azonenberg_work has joined ##openfpga
<rqou>
azonenberg_work: why are you always being the safety inspector?
<azonenberg_work>
rqou: Lol... my tweet?
<rqou>
yeah
<azonenberg_work>
it just jumped out at me while looking for a place to eat
<rqou>
although i suppose the standards for commercial buildings should be enforced
<azonenberg_work>
precisely, especially heavily populated areas like airports
<rqou>
what about everybody's favorite place for EH&S violations - university labs? :P
<azonenberg_work>
I complained about them when i saw them
<rqou>
how about almost losing your insurance because people OD'ed in the housing co-ops too many times? :P (cc awygle)
<awygle>
rqou: only time i lost my health insurance was because i had to drop out to take a co-op :P
<rqou>
lol i was referring to Cloyne and the resulting lawsuit
<awygle>
cloyne was always a shitshow when i was there, i mostly avoided the co-ops
<rqou>
yeah me too
<rqou>
amazingly they appear to have succeeded (for now) in making cloyne substance-free
<awygle>
what about bedbug free?
<rqou>
idk about that lol
<awygle>
scabies-free?
<rqou>
see, these problems don't cause the university to lose their liability insurance, unlike ODs
<rqou>
:P
<awygle>
they probably should
<awygle>
but yes
<awygle>
related, has anybody in foothill been treated for scurvy recently?
<rqou>
what
<rqou>
did that happen?
<awygle>
"first year engineering student eats nothing but ramen, gets scurvy" was a thing for a while
<rqou>
i didn't hear about that happening
<awygle>
i never saw any credible evidence that it happened at all, but it's a great rumor :P
<rqou>
i did hear a story of somebody who was soldering in the dorms and blowing the fumes out the window causing an RA to come in and ask "wtf are you guys smoking?"
<qu1j0t3>
LLOLLLLL
<qu1j0t3>
awygle: that reminds me of the other growing genre, 'kid mines bitcoin in bedroom, gets heatstroke and nearly dies'
azonenberg_work has quit [Ping timeout: 260 seconds]
<rqou>
i do remember hearing about that on reddit
<qu1j0t3>
that scurvy thing could also be a segue to pie_ 's comment about Puerto Rico -- looking at the "food" provided by the feds
<rqou>
(old meme) does it involve pizza as a vegetable?