ice799

I built https://packagecloud.io to help make creating, hosting, and installing APT (and other) repositories easier. Check it out :D

Thanks!

Check out my above comment and feel free to ping me via email or twitter. Would love to get more detailed feedback from you and maybe try to change your mind!

Hi!

Just for fun: man reprepro and search for 'corrupt' :)

You can use all your normal tools to upgrade, install, and remove packages as you normally would. So, for, Debian-based systems, apt-get upgrade, install, remove, etc all work as you expect.

We provide SSL, gpg, and fine-grained access control all out of the box. Fine-grained access control doesn't really exist with reprepro or createrepo or other tools and you'd have to build it yourself.

Also, you don't need to worry about backups, the numerous bugs in all the repo creation tools, and we have chef and puppet modules to help deploy this across your infrastructure.

We have support for multiple linux distributions in a single repo (quite a pain to deal with yourself) and best of all we also support pushing multiple versions of a single package to a repo -- something that reprepro does not support, but has been in progress for ~4 years [1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570623

I thought it was pretty crazy that a tweak to prevent XFree86 from breaking on 64bit systems + support for the ELF small code execution model would later result in pthread_create overhead so large that creating threads on a P4 would be as slow as creating threads on a 386.

But, hey, maybe it isn't that crazy to you.

lolruby

search the page for linux and check the tags at the bottom. says linux a few times bro.

hi. linux does have this.

you just strip the debug symbols out (and put them somewhere safe). then write a .gnu_debuglink section to the stripped ELF binary with a CRC that matches the stripped symbols.

once something bad happens: you just take the core dump, the symbols you have tucked away, and you are able to debug just fine.

the gzip bug mentioned did not segfault. it simply corrupted the gzip file in memory. not that selective son.

imma talk the way i talk and dont give a fuck if you like it or not.

You are totally missing the point, bro.

The question really is: how much data corruption is occurring that _does not_ cause world ending segfaults? THAT is what you need to worry about. Check yourself before you wreck yourself.

registers are scanned, too. the bug is not that the ref is in a register. the bug is that there are no refs anywhere. not on the stack and not in any register.

thanks man. i've also updated the graphs on my blog.

done, refresh page and you should see em.

grossly exaggerated? bro, i gave the raw numbers in a table above the graph. if i were trying to lie i wouldn't have given the numbers.

i took the graphs as-is from goog docs and put em in my blog post.

i just zero-based the vertical scale. you can close your book about lying with stats or whatever the shit.

Spilling has nothing to do with this. GCC has the chance to pick another GPR that is caller saved but instead picks a callee saved register.

This decision increases the size of libc by 1% when compiled with -fomit-frame-pointer[1].

[1] http://sources.redhat.com/ml/libc-alpha/2010-07/msg00022.htm...

building the code in the bug report as a 64bit binary and various system information: http://gist.github.com/483494

and

testing harness, scripts to build it, and to run it: http://gist.github.com/483524 -- yes i was too lazy to make a makefile.

you will still need to construct some command line fu to separate the results into separate files so you can load it into whatever maths program you want.

Chill, son.

1.) I can provide the codez. I'll add a link to the article.

2.) Yeah. If you read the article, it reproduces on 64bit code, too.

3.) Not true. Try gcc (Debian 4.3.2-1.1) 4.3.2. The version I mentioned that I used in my post.

4.) etc

5.) Read the article.

I'll add some more shit and reply to you again when its online. I need to eat breakfast and head to the office but I'll make you happy soon.

sorry bro i write the way i talk. also: "shit, piss, fuck, cunt, cocksucker, motherfucker, and tits."

what's wrong with that? i removed that part from the conclusion to help fix your butthurt.

i don't do graphics bro sorry

a couple months working in our spare time after work/weekends.

This.

I built this because I like working on this sort of thing and because it lowers the bar for everyone else who doesn't know how to or want to rebuild their binaries.

Also, depends a lot on your infrastructure. Sometimes it's easier to distribute and maintain patched Rubies, and sometimes it's easier to just require a ruby gem. The gem is designed and built in such a way that it should be resistant to most changes made to the Ruby VM.

I didn't hardcode any addresses. That's why it works on so many different Ruby builds.

thanks, glad you liked the slides.

working on it.

yup, it was recorded. not sure when the video will be out, but i'll tweet it or something as soon as i hear.

glad you liked the slides.

Fun challenge! I wonder when the contest closes? I'd like to blog about my solution. Hopefully my email to matasano doesn't get eaten by a spam filter :/

Firstly - thanks for reading the blog post.

Some of the things mentioned help to reduce CPU usage so that the CPU can do more useful things (TSO, IOAT, DCA, NIC irqs, etc). ioat moves a surprising number of bytes for the CPU. You might be surprised at how many.

I probably could have (and should have) included a bit more variety, though.

Thanks for reading.

Indeed - but flipping the "DCA on" switch in the BIOS sets the bits in these registers.

So it is different, but it does the same thing.