anonymouscowar1

Ok, Sir Snark-a-lot. Yes, he was clearly good at other things. I don't mean to shit on this guy's skills. The article goes to a lot of trouble to claim that he has an "edge" over other con-men; but, it turns out that that edge is just be a few trivial tricks. I was underwhelmed.

So apparently the only thing this guy had going for him was that he could print checks with magnetic ink and fake a caller id. Both are trivial. Wow.

Oh, this guy is an asshole, and what he writes definitely falls into a defamation and slander. The First amendment doesn't protect this kind of speech.

The problem isn't that he's being punished by the courts, it's that he's seeing indefinite jail time just for opening his mouth. There is a crime here, but the punishment doesn't fit it.

20% (4.8 hrs)? I don't know about you, but for me it's closer to 33%.

It wasn't a hack us contest, just a bug bounty that applied to a limited number of domains (not including whatever site the dropbox password went to). That's what I remember, anyway.

Then you can just create a new, younger start-up and acquire the older one. Taxes fixed at 0.

Is NY trying to race to the bottom?

Linux is hard, let's go shopping!

Package repository may bump versions without warning, and lags behind gems. There is no typical lag time, it's updated whenever the packager feels like it. You can file bugs at redhat bugzilla to try and motivate them to update packages sooner, if you want something specific.

On the plus side, you get security updates, and any gems that are packaged should be compatible with each other to some extent. In general, I think ruby packages are good for end-users, but maybe not great for developing ruby applications or other gems.

(I don't mean to rag on Fedora packaging here — I'm a Fedora packager! I just want people to be aware of the limitations of distro packaging.)

Presumably if you want syslogd's features, it's for something other than the text log files (logging to SQL, network logging, ...).

Can you suggest a good one for Android? I am missing ABP sorely.

Not if the tax bracket gets lower at 20-50x the median income. Tax brackets should be monotonically increasing.

> before the repne scasb. Did I screw that up?

Ah, it's possible repne scasb halts when ecx drops to zero (that would explain some of the string length asm code I found when I googled it). I'm not very familiar with x86 mneumonics apart from the basics ('mov').

> four million packets per second (well, one million until I parallelize), which is about 85 megabytes per second

Why is this more than 4 million bytes per second (4 MB/s)? A packet can contain a single byte.

So, question: what sits in memory below the bottom of the framebuffer? It seems like if a sound interrupt occurs while drawing the lowest-address tile, you might corrupt something below there.

Edit: Oh! Just got to footnote 2. Thanks, author!

More and more, like this. In the bad old days, it was more of the latter.

Do people try and optimize Haskell programs? This is a part of Haskell that terrifies me.

It's hard to be vulnerable to XSS and CSRF with all-static content, no?

So, not only will a trickle DoS other clients, each byte will also force an O(n) traversal of $buf (burning CPU). Granted, buf is only 1000 bytes, but that's not great.

It looks like a request with no space could force you to walk (`repne scasb`) through invalid memory after $buf. Also maybe corrupt it (unescape_request_path).

It will also fail to correctly parse HTTP/0.9 (not a big deal, but part of spec). The parsing code ignores the existence of verbs other than GET. (Doesn't check that the verb is GET either.)

We don't validate that paths start with /, we just skip that byte. Okay:

        mov (path), %al
        ...
        cmp $'/, %al
        je badreq

Since valid GETs are of the form:

    GET /foo.txt HTTP/1.0
         ^-- path=buf+5

As you point out, a client close will cause SIGPIPE causing a crash (DoS).

That's all I see. But I'm not an asm expert and I'm sure I've missed something.

Sure, sometimes they warn about totally valid behaviors. The "all warnings must be fixed" dogma arises not out of the belief that all warnings are errors, but rather that the value of having compiler warnings catch bugs early is well worth the cost of changing code style to conform to the compiler's warnings suite.

The BSD solution to this problem is __DECONST(), a macro which basically casts through `uintptr_t`.

    #define __DECONST(type, var)   ((type)(uintptr_t)(const void*)(var))

Some of those auto-camera-targetting laser cannons from Pirate Cinema would be awesome.

Me too. You could probably find a single-threaded, small file benchmark where they compare similarly (or this even compares better — it does almost nothing). But this is not most benchmarks. Large files or multiple clients will bench this server poorly compared to MT + sendfile(2).

This server is single threaded and artificially serializes requests, at a minimum. The copy through userspace is going to hurt compared to sendfile for larger files.

Yeah, the problem with OpenConnect is that every time they bump the 'cstub' binary on the cisco remote end, OpenConnect stops working until you grab the new one somehow.

('cstub' is a wonderful program that is downloaded over HTTP and runs as root. It's supposed to monitor security, or something. I did mention I run this on a VM, right?)

This is not a very fast webserver. Anything using sendfile() and threads/processes will beat it handily.

This is a simple, single-threaded single-process accept-read-respond-loop web server. It's vulnerable to trivial trickle DoS attacks and probably has other issues. There are no advantages, the author just did this for fun.

The TCP part comes from C code in the kernel, so this headline is a little misleading ;-).

Are you kidding me? This is pretty fucking arrogant. My $DAYJOB is FreeBSD kernel hacking.

Reusable piped programs are great for some things, especially a productive shell language. No, composing processes is not great for all things, and certainly not where performance is required. This is why FreeBSD is a monolithic kernel instead of a microkernel with processes, for example.

Spawning a program is incredibly slow, even ignoring disk read times, compared to 3 levels of low-branch-factor search in any language.

The client side of the VPN is pretty straightforward. It's a closed source program that basically creates a `tun` device. So I run it in a VM so it can't harm my home machine, and just use iptables to route work traffic to it. No idea what is needed on the infrastructure side.

No idea how much the video costs either, but my employer is a Fortune 500 company.

My company uses a Cisco VPN and Cisco jabber video chat for remote workers. I run the VPN client in an Ubuntu VM on VMware Workstation.