-
I do Haskell stuff.
Twitter NLP bot
Github events -> IRC bot
Book, g'dammit.
Talking to publishers about #3
PR’d the twitter-types Haskell library, probably continue to kick that around as #1 develops.
Hoping to avoid Haskell infra work this week (Hackage, Cabal), but it seems like I might end up fixing Hackage-Fu.
-
github link for the twitter nlp bot?
-
It’s still very, very early. It’s a project for a student to learn NLP + Haskell + API access + data persistence.
There’s nothing interesting yet. Rest assured, it will be posted to lobste.rs when it has expanded a bit. We’re still figuring out how to pull down and analyze data.
Also, it’s a bot obsessed with pie. Just pie.
To give you an idea of how early: we haven’t even tested a dumb, manual scoring lexicon with word normalization - let alone a topic model / classifier.
-
There’s nothing wrong with being obsessed with pie.
-
-
-
-
-
Floatingice
3 years ago
|
link
| on:
Looking for some technical people to help Beta test a TCP accelerator I'm launching. Sign up here.
I read the article. It seems like the protocol you’ve implemented takes
Inputsthe inter-arrival time of acknowledgements, changes in round trip time, including the minimum, the moving average and the variance, the number of consecutive packets lost per each loss event, the historical instantaneous buffer bloat at the time of loss events, estimated link capacity and the ideal bandwidth delay product needed to fill it
and acts more aggressively based on this information, is that correct?
If you’re acting more aggressively won’t that inherently increase congestion when an additional draw on network resources becomes active? You’re inherently going to incur losses, but you’ll refuse to back off as aggressively as normal TCP.
I’ve never tried RDP + Bit Torrent.
In order for your Super TCP to work though, it would have to understand application level in order to separate flows, otherwise wouldn’t it simply balance RDP as a single TCP flow and bit torrent would open many TCP flows? It is unclear how your service achieves this. It seems it would need to be an OS patch, or implemented in your router, which then does TCP termination for local clients. This is how a lot of the WAN accel proxies work (riverbed etc.)
-
Correct. However, our protocol will be more aggressive only if there are no signs of congestion. If other flows become active, SuperTCP will indeed backoff and share the resources. This works the best if the other flows also use SuperTCP. If many other normal TCP flows are contending for the same bottleneck, congestion is inevitable, in which case all flows may experience losses and backoff accordingly.
Furthermore, while normal TCP will wait for congestion loss to occur before backing off, SuperTCP will actually slow down upon early signs of congestion, decreasing the chance of queue overflow. Even without application level traffic shaping, this latter feature can improve the QoE of RDP sessions, as the extra latency from buffer bloat is minimized.
-
-
Floatingice
3 years ago
|
link
| on:
DRAM security threat: Flipping Bits in Memory Without Accessing Them
Has anyone tried testing this sort of thing on two virtual machines running on the same machine?
From reading the presentation it seems like they could be vulnerable - which means if you happened to get a server on the same physical machine you could start getting other local VMs to crash. It would be truly impressive to run a successful exploit this way!
On the plus side, it seems like it would be difficult to get a web service to perform this sort of attack for you.
-
-
Nice. Ordered 5 for the Lobsterers at my office.
I’d like to get better at running an interview process. Currently, I way too often fall back onto soft reactions to inessential markers (“oh, you were at X while I was at Y!”). Surely there must be a better way than “two dudes staring at you while you flounder at a whiteboard” or “shoot the shit with someone about some random technical topic”.
Here’s my interview summary:
00:00-5:00 : introductions / figure out the interviewee
05:00-30:00 : programming questions
30:00-45:00 : wrapping up + b.s. with bad candidates, selling + personality with good candidates
My interview is pretty straight forward. The first 5 minutes, we do introductions, I figure out what kind of coder they are and which languages they prefer and then ask them one of my two interview questions. I also want to avoid getting to know the person too well before I figure out if they can code.
Non-embedded people get lists / trees algo questions. (phase 1, 2, 3) Embedded folks get memory management or memory manipulation. (phase 1 - understand the initial problem, 2 -manage memory, 3 - cleanup)
The question is designed with graded difficulty - if they solve the first phase, they hopefully will uncover the ‘trick within a trick’ and have to improve their solution. Generally the stronger candidates will get to this stage on their own, but weaker ones will fail to. That’s okay!
Depending on the time frame, if there is not enough time remaining and it is clear the candidate will fail to solve the problem, I help them through phase 1 and 2, and then I congratulate them on their solution. I wrap up the interview with them talking about themselves or some facet of their resume that is interesting. I’m not going to hire them, but I want them to feel okay about the interview.
The smart ones will solve the question in about 15-25 minutes, getting through all 3 phases. This leaves me with time to sell them on our company, the work we do, and find out more about their personality / projects.
The interview answers. 1. Can they code? Yes - they can code, are they a nice person to work with and have they done interesting projects No - it doesn’t matter if they’re nice, they’re not a fit for the job.
I prefer Strong Hire, or No Hire. Personally the cost of not hiring someone is low. I would prefer to keep the bar high.