<zrafa>
OMG, that thing is set as GPIO for the keyboard
<zrafa>
!
<zrafa>
I want to kill myself
<sung>
do any of you know what an ethernet network transformer is for?
<whitequark>
sung: sure
<sung>
i'm reading through schematics and i was wondering why ethernet pins aren't going str8 to a jack
<sung>
but rather hittnig up a network transformer, and then a jack
<whitequark>
ethernet uses differential signalling; the transformer removes DC offsets and allows pulses to pass through
<whitequark>
DC offset*
<whitequark>
since you have a twisted pair, any voltage that's induced in the pair due to external interference is induced with roughly same magnitude in both wires
<sung>
ohhhh.
<sung>
okay, so just because an IC has a PHY, doesnt necessarily mean it has a built-in network transfoemrmer
<whitequark>
there's also Power over Ethernet, which puts 48V between some two pairs
<whitequark>
with a transformer, you can still use them for data
<whitequark>
yeah, putting a transformer into an IC is a pain ;D
<sung>
bro, thank you.
<sung>
and it looks like i can find ethernet jacks called magjack that has it builton
<whitequark>
yes, plenty
<whitequark>
"magjack" though? not sure. I always seen some noname chinese connectors, never with a fancy name like that
<whitequark>
>This countermeasure will only fail if both A and T are infected in exactly the same way. The second compiler can be malicious; it just has to be malicious in some different way: i.e., it can't have the same triggers and payloads of the first.
<whitequark>
in essence, the effort required to detect this hack is not even within an order of magnitude of effort that is required to produce it. it's way, way easier
<whitequark>
and this process in fact happens in the wild all the time, e.g. when clang and gcc bootstrap each other
<viric>
kyak: the fun is that Ken wrote the C compilers in the go toolchain :)
<kyak>
whitequark: ok, i'm reading now
<viric>
would you trust compilers from Ken?
<whitequark>
no; they created C.
<whitequark>
economically, likely the worst thing to ever happen to computing.
xiangfu has quit [Remote host closed the connection]
pcercuei has quit [Ping timeout: 255 seconds]
<viric>
:)
<kyak>
whitequark: ok, i get it
<kyak>
whitequark: so, when clang and gcc "DDC" each other, is V and W bit-to-bit equivavelnt? :)
<whitequark>
kyak: compiler bootstrapping does, in fact, check bit-for-bit equivalence
<whitequark>
as part of natural testing process
<whitequark>
but it's not really about that
<whitequark>
my point is that, for example, LLVM's history is public and cryptographically signed, and its internal structures change a LOT
<whitequark>
ditto for GCC. it's simply not possible to write a payload that would work on future versions of LLVM; you can't predict the future
<whitequark>
so even if *at some point in past* this happened, it's not working anymore
<kristianpaul>
zrafa: yeah..
<kristianpaul>
rx pin keyboard :p
<kristianpaul>
you already need more help? :)
pcercuei has joined #qi-hardware
<kyak>
whitequark: i'm thinking if DDC would work for cross-compilers.. For example, gcc-arm - is there any compiler other than gcc that can compile gcc-arm?
pcercuei_ has joined #qi-hardware
pcercuei has quit [Ping timeout: 250 seconds]
pcercuei_ has quit [Ping timeout: 250 seconds]
pcercuei has joined #qi-hardware
<whitequark>
clang, of course
<ysionneau>
clang can compile gcc ? :)
<ysionneau>
cool!
<whitequark>
what? of course clang can compile gcc
<whitequark>
why is this even a question/
<larsc>
maybe gcc requires some strange gcc extetensions ;)
<ysionneau>
I would expect GCC to contain crappy code that only GCC could ever compile :)
<ysionneau>
that would not surprise me at all
<whitequark>
larsc: well, it sorta does
<whitequark>
it won't compile on a strict C99 compiler afaik
<whitequark>
maybe with some hacks
<mth>
I thought that GCC recently switched to C++
<viric>
they started to welcome c++ code
<viric>
clang is more or less designed to compile what compiled in gcc, no? :)
<ysionneau>
that's the goal yes
<viric>
so no wonder that it can build gcc
<ysionneau>
but there is always some code somewhere that depends on some gcc specific behaviour
<whitequark>
viric: indeed
<ysionneau>
and that will break on clang
<whitequark>
although it rejects the more egregious hacks
<ysionneau>
this is becoming less and less true though
<larsc>
clang for example does not support variable sized arrays on the stack
<larsc>
which is only support by gcc by accident
<larsc>
supported
<larsc>
because they needed it for ada or something
<viric>
alloca ftw
<viric>
:)
<whitequark>
clang has alloca, of course
<viric>
variable sized arrays should be doable and easy.
<whitequark>
if it was the case, they would be supported
<whitequark>
take a look at clang's ML for details.
<viric>
that was a quick though
<viric>
t
<viric>
I'll read about it another day. Good that there is discusison though
<whitequark>
I have no idea honestly, but I know that clang devs don't drop a feature solely because of ideological concerns or something
<whitequark>
if it's not supported, it has a good reason behind it.
wolfspraul has quit [Quit: leaving]
<viric>
good reasons don't mean easy agreement :)
<viric>
but can be. I don't use clang at all
<whitequark>
generally it is maintainability concerns
<whitequark>
gcc exposes a lot of accidental implementation details
<viric>
I never tried to write a compiler, so I might be not any good to judge :)
<larsc>
well they are not part of the standard
<whitequark>
larsc: clang implements plenty of extensions
<whitequark>
if you want standard, use -pedantic :D