<larsc>
nicksydney: you really need to get a twitter (or a thimbl)
<nicksydney>
larsc: nah too old fashion twitter...should get twitIRC :)
<ysionneau>
twitnet
<ysionneau>
telter
<ysionneau>
over COM over BLE
<wpwrak>
and no audio peripherals in anelok :)
<wpwrak>
(COM, etc.) 110 bps teletype
freespace has joined #qi-hardware
xiangfu has joined #qi-hardware
<nicksydney>
i don't understand why people are so excited when they can do programming in a microcontroller such as Cortex-M series using Javascript or .Net ?
<wpwrak>
because they won't have to live with the confusing fact that some C on a cortex runs faster than their junk on the PC that's supposed to be 1-2 orders of magnitude more powerful ...
<nicksydney>
hmm....still not convincing to write in JS though
<ysionneau>
well, for some use cases you prefer python rather than C, right?
<ysionneau>
some people are very much more productive in python or JS than in C
<ysionneau>
for string manipulations for instance
<ysionneau>
so I can understand some people would like to be able to write code for uC in python or JS or some language like that
<ysionneau>
which is "easy" to write
<ysionneau>
and moreover it's cool to be able to play with the interpreter interactively
<sb0>
because C is a pain?
<sb0>
even the problem of concatening strings doesn't have a proper solution with that crap language
<whitequark>
because C is a truly terrible language
<whitequark>
Rust is as powerful (for wpwrak: performant) as C, it's not shit, and "Ruby hipsters" are somehow pretty fine with it
<ysionneau>
is Ruby still a hipster language ?
<ysionneau>
I would imagine that hipsters would be on to something new and shiny now :)
<sb0>
define: "hipster language"
<ysionneau>
a language which attracts hipsters?
<whitequark>
meh, doesn't matter. what I mean is, the fact that C is hard to use and the fact that its compiler can produce tiny/fast binaries are orthogonal
<sb0>
well, anything can attract hipsters...
<ysionneau>
true
<ysionneau>
especially when it's "new"
<ysionneau>
and has nice features for rapid development like scaffholding
<ysionneau>
even if it's usually more a demo stuff than anything else
<sb0>
I wonder how much a hardware memory manager (malloc/gc) would make sense
<sb0>
with safe pointers
<whitequark>
sb0: but you don't *need* hardware to hold your hand there...
<sb0>
yes, you can have a VM of course, but it's slow
<sb0>
I know JIT makes it faster
<whitequark>
VM?
<whitequark>
have you seen how Rust solves the problem?
<whitequark>
you don't need a VM to get memory safety
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #qi-hardware
lamrz has joined #qi-hardware
<wpwrak>
ysionneau: for string-heavy stuff, i use perl. better syntax :)
<whitequark>
so if you want to have systems software that intensely manipulates strings--say, any old-days protocol, like SMTP or IMAP, ever--you're fucked
<wpwrak>
well, in this case i have to make a little extra effort. like write a string lib for C. or reuse one i've already written. depends on the task. didn't need heavy string-processing for a while.
<whitequark>
you should review one day the history of remotely exploitable vulnerabilities for FTP servers, mail servers, DNS servers (especially BIND), ...
<wpwrak>
most of my programs are the batch type: read all inputs, process, spit out results.
<whitequark>
every single one RCE in them could not exist if it was written in a memory-safe language
<whitequark>
tell me again how C is a good systems language
<wpwrak>
oh, i grew up with ftp exploits ;-)
<wpwrak>
if you need to do things with strings that make you uncomfortable, encapsulate the tricky functions. just like your critter does somewhere, too.
<wpwrak>
if you don't feel up to the task of making your own abstractions, look for some library that does it for you and learn that library
<whitequark>
no amount of encapsulation will save you from use-after-free (for example)
<wpwrak>
i find it more convenient to just adapt to the situation, exploit the sweet spots
<whitequark>
or in other words, accidental incorrect usage of the API of that library which the compiler won't find
<whitequark>
besides, your advice is irrelevant. I certainly admit it is *possible* to write secure code in C
<wpwrak>
if you're terminally afraid of free, then don't use it in your code. encapsulate it and add run-time checks as needed
<whitequark>
but in practice this mostly doesn't happen
<ysionneau>
15:41 < wpwrak> ysionneau: for string-heavy stuff, i use perl. better syntax :) < *chockes*
<whitequark>
no amount of encapsulation or runtime checks or even code reviews saved openssl from being a piece of shit
<whitequark>
it did everything you said
<wpwrak>
perhaps the main problem of C is that it encouraged unwarranted confidence
<whitequark>
you could describe it like that, yes.
<wpwrak>
and no, openssl still exposed too many low-level things. if you want such abstraction, you have to be consistent
<whitequark>
hardly changes the consequences, which are: if you want to exploit a Linux system, you can
<whitequark>
remotely, locally, pick whatever you like
<wpwrak>
(too many) in relation to the quality of the review process and coding standards
<wpwrak>
there are many ways to make your code secure, but you have to be consistent
<wpwrak>
btw, the "new heartbleed" is also from the same author. i guess his commits will come under very close scrutiny now
<ysionneau>
latest changelog showed how many security issues? 6?
<ysionneau>
crazy :o
nicksydney has quit [Remote host closed the connection]
<whitequark>
you'll also find that he isn't a particularly bad coder (or much less an NSA agent)
<wpwrak>
which means that he's either losing a job, or he'll learn a lot about himself ;-)
<wpwrak>
there are certain very fundamental coding practices that can help you a lot. like making small functions that do one thing and do it correctly
<wpwrak>
so the heartbleed copying should have been one such function. it would have stuck out immediately.
<whitequark>
there is also a very fundamental coding practice that eliminates *all* memory-safety bugs, which is strictly better than what you suggest...
<wpwrak>
the tendency to write long functions doing a ton of things is either laziness, ignorance, or some bad habits learned from C++
nicksydney has joined #qi-hardware
<wpwrak>
C++ being a much inferior language to C
<whitequark>
it's also hilarious that you crap on C++ while it helps quite a bit with encapsulation that you like so much
<whitequark>
and factoring common code out
<whitequark>
if you omit about 99% of C++, you can write good code in it :p
<ysionneau>
to me C++ code is very hard to follow, but I don't have much experience with it so it might be the reason
<wpwrak>
nothing wrong with OO techniques. but you don't need new languages for that, C handles them just fine as well
<whitequark>
actually, there's a lot of things wrong with OO techniques. the advantages of using C++ lie elsewhere
<ysionneau>
Good old friday troll is coming :) I feel it
<wpwrak>
C++ encourages poor style. first, it's very hard to determine what your classes really contain. second, you can't break down methods like you break down functions, leading to monster methods.
<wpwrak>
OO should be used sparingly, where it makes sense. in C++, you feel obliged to use it for everything. hence bad code.
<wpwrak>
sb0: i see a lifetime achievement award ;-)
<whitequark>
wpwrak: since you're so good at C, can you find a bug here, which makes the KDF nearly useless? http://pastebin.com/gYMLpVSe
<wpwrak>
looks correct, C-wise, though not fully defined. there's also an unfortunate mixing of sizes as constants and open-coded numbers
<wpwrak>
btw, if you want proper type safety for arrays, put them in a struct
xiangfu has quit [Remote host closed the connection]
xiangfu has joined #qi-hardware
FDCX has quit [Ping timeout: 265 seconds]
FDCX has joined #qi-hardware
<wpwrak>
it's of course not strictly portable, but i don't think there are any real platforms with pointers > 128 bits yet. you may want to add an assert, though.
<whitequark>
wpwrak: it's not correct
<whitequark>
it's critically wrong, and any code using it would be terribly insecure
<wpwrak>
as long as your pointers are short enough, it will run fine
<whitequark>
there's no undefined behavior there, true
<wpwrak>
and yes, it's obviously not very secure. especially not on machines with small word sizes
<whitequark>
but it is not correct and you only have to know C to determine why
<whitequark>
small word sizes, hm?
<whitequark>
what about them?
<wpwrak>
because of sizeof(pointer)
<whitequark>
yeah, that's the bug
<whitequark>
should've used AES128_KEY_LEN there
<wpwrak>
or a struct, as i suggested :)
<wpwrak>
arrays as arguments are generally not a good idea
<wpwrak>
hmm, is it really necessary to have two chokes on the earpiece ?
<whitequark>
eh?
xiangfu has quit [Remote host closed the connection]
<wpwrak>
or sorry, wrong channel :)
<wpwrak>
(trying to decode the n900 design)
<eintopf>
:)
<whitequark>
hmm, for my pump I bought a 3A adjustable SMPS for ~$25
<whitequark>
decided it's more economically efficient to not make one myself
<whitequark>
based on some Linear thingy... let me look at it
rz2k has quit [Read error: Connection reset by peer]
<larsc>
were you expecting selfies with sepia filters?
* whitequark
is offended
<kyak>
whitequark: i'm just kidding --)
<whitequark>
(I'm not really offended)
lamrz has joined #qi-hardware
lamrz has quit [Read error: Connection reset by peer]
lamrz has joined #qi-hardware
lamrz is now known as 1JTAAC5F6
1JTAAC5F6 has quit [Client Quit]
<DocScrutinizer05>
nasty choke
lamrz has joined #qi-hardware
<whitequark>
what about it?
<DocScrutinizer05>
well, it's "open"
Jay7 has joined #qi-hardware
<whitequark>
EMF?
<DocScrutinizer05>
kinda, yes
<whitequark>
EMI, rather
<DocScrutinizer05>
it's prolly for "DC", right?
<whitequark>
it's DC-DC
<whitequark>
0~40 to 0~37
<DocScrutinizer05>
yeah, so you can conveniently check for current with a analog Hall-sensor ;-P
<whitequark>
hehe
<whitequark>
hm, noticed I have nothing to gate its input with... damn
<whitequark>
need a tiny SSR there
<DocScrutinizer05>
and with a secondary coil nearby you can check for noice and hum on the DC
<whitequark>
or not even SSR actually, any relay would work.
<whitequark>
althoooough not actually, no, a regular relay will get its terminals fused shut
<whitequark>
while disconnecting 1A flowing through a massive inductor
<whitequark>
(the motor)
<whitequark>
O_O fuck, SSRs are expensive
<DocScrutinizer05>
yep, with a proper mosfet you're better off
<whitequark>
cheapest relay I can find is... $5
<whitequark>
well. hm.
<whitequark>
and any inductive loads are conspicuously absent from relay datasheet
<whitequark>
I bet the contacts *will* get fused
<whitequark>
contact material claimed AgNi 90/10
<whitequark>
hm, that should work ok
FrankBlues has quit [Quit: Leaving]
wolfspraul has quit [Quit: leaving]
<DocScrutinizer05>
you shouldn't switch inductive loads with a relay, unless you use a clamp diaode
<DocScrutinizer05>
diode
<DocScrutinizer05>
or alternatively an RC spark extinguisher
<DocScrutinizer05>
you said it's DC. Great for R-C
<DocScrutinizer05>
R rated for not exceeding relay's max I on contact-close, C dimensioned to not exceed charging to voltages > say 100V during the time the contact needs to open, on nominal load of your motor or whatever
<DocScrutinizer05>
I.E when you have 1A and the contacts need 50mS to completely open, then your C shouldn't charge to >100V in 50ms with 1A current
<DocScrutinizer05>
R needs to limit current to < say 2A (max current according to datasheet of your relay), at 40V