emillon

That's quite surprising, it's a textbook XSS vulnerability. It seems to me that their markdown library should escape entities by default or they will have many other vulns.

pickle is a (de-)serialization library for Python. It allows arbitrary code evaluation, so shouldn't be exposed to the outside world (for the same reason that we have JSON parsers and don't use JS eval() to parse JSON).

Σ(2^i / (10^(5i)) = Σ(2/10^5)^i = 1/(1-(2/10^5)) = 10000/9998

(you get the idea)

It's not unlike the busy beaver problem, where you have to produce the highest number with a turing machine before halting:

https://en.wikipedia.org/wiki/Busy_beaver

It's not calling the git command that's problematic, it's calling an external command at all. So you pretty much have to recode the hot part in another language, where you just manipulate buffers instead of piping stuff around.

Rot13 for spoilers:

Jura vaibxvat tvg va n furyy ybbc, lbh'er jnfgvat lbhe gvzr sbexvat. Qbvat guvf va n fvatyr cebprff jvyy fcrrq vg hc n ybg.

Thanks!

Can you make it available somewhere? I'd be interested in that data, and sure that others would be too. Thanks!

The difference is in the error message you get. Adding "if (x == NULL) abort()" will display a backtrace near the error. To understand the cause of the segfault, you will have to follow the data flow in your favorite debugger.

> I remember holding it in my bare hand in chemistry lab (encouraged by the teacher).

At a (not so remote) time, students used to put their hands into mercury to demonstrate that it is liquid but not wet.

And fixes the permissions. With /etc in git it becomes world-readable.

This was covered on PBD:

http://programmersbeingdicks.tumblr.com/post/68153753288/pen...

The big problem for me is the compilation time, which is very slow (this may or may not be because the compiler itself is written in Rust).

I dedicated a few days to hacking on rustc this summer, and while the tooling and community are very nice, the compilation times are really high. Git pull && make ? 20 min. Edit a file && make ? 5 min. IIRC the major was that metadata got serialized/unserialized all the time, but anyway it's one of the priorities. I'll hack again on it with pleasure when I'll have more time.

Undefined behaviour is a dynamic property, not language constructs. It's akin to saying "remove run-time errors from your programs".

Thanks!

I think that the commit history says a lot about the development process and the company culture. First, is that it's interesting to see how these companies work internally. Second, it's easier to dive into the code by reading the latest commits. You can see what's going on and what pieces are changed together. Finally, there is a substantial difference between:

- a repository that's handled as a first class "source code ledger" (pick one or several of: proper branching/merging, atomic commits, issues referenced in commit messages, etc).

- a repository full of "git commit -a -m 'ill fix this bug later, TGIF'" whose history makes no sense.

I don't want to open the debate on which one is preferable or not (most people agree that git bisect is handy, but it is open to debate whether it's worth the cost).

What I'm wondering is how it looked and why it was rewritten. The most probable reason is that they wanted to make sure that nothing sensitive was exposed (non-redistributable embedded dependencies, information on their infrastructure, ...). But it's also possible that this was started as a type-2 repository and they don't want to expose this image.

I tend to think that every code should be written (and developed) as it was open sourced one day, but as always there's a cost trade-off in here.

Anyway, thanks for open sourcing this piece of software!

I understand that it's not worth the cost to cleanup the history, but it's always frustrating to see such a project come with a 100kloc "initial" commit.

Snapchat works like this and is reasonably successful. But of course, there is no technical way to enforce the ephemeral aspect.

When microwaving a CD, the induction stops when the track is cut. There are usually big chunks of surface (~2cm²) unaffected. You can't read it with your drive but it's reasonable to think that some data can be retrieved from it, with enough work and money.

Interestingly enough, the switches are not electric ones. It's just something that can be physically (maybe even optically) detected by the device.

X32 code is different from "plain" 32 bit code (x86 style) as it still runs in long mode and can use all registers.

Make only understands rules such as "X depends on Y", but gcc can output these dependency rules (-M* switches). So yes, it is possible to do this but make itself is source code agnostic.

There are very few releases of GNU make: 3.81 (in Debian too) is from 2006, 3.82 from 2010 and 4.0 from 2013.

That was between S12 and W13:

http://ycombinator.com/w13smaller.html

I can't find the source for the cut in extra VC funding but it was around the same time.

The difference is that Haskell does not check types at runtime like Clojure does (which is the point of strong static typing), so if the type is wrong it becomes as unsafe as C.

> Processor speeds double approximately every generation which we can estimate is once every two years.

Do you have any sources to back up this claim? Max processor speed has stalled to ~4GHz since 2005. If you're referring to Moore's law, it concerns the amount of transistors in ICs, and will eventually hit a limit (not before 10 years, but not after 140 years).

The background of this post is a thread on the debian-python mailing list, relative to a new PEP:

http://lists.debian.org/debian-python/2013/09/msg00049.html

What buttons will you push?

It's actually being integrated in Debian. (right now it's in the NEW queue, ie it's under final copyright review). See this bug report:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447

I read the link, and I disagree that it answers these questions. It is presented as "the truly open source successor to the ZFS project", which is why I understood it was a fork.

I agree that btrfs is not ready for production (and I'm not ready to hand my precious bytes to it yet), and will probably never be as feature rich as ZFS. But the licensing issue will always exist, and Linux needs a modern file system -- btrfs.

That said, a lot of people/businesses use ZFS on Linux in production, so it's nice that there is an central place where they can find documentation about it.