jespern

This works for me:

  import hid

  VID = 0x046D
  HID = 0xB023 # 0xB35B

  if __name__ == "__main__":
      h = hid.device()
      h.open(VID, HID)
      h.set_nonblocking(1)

      # this works for keyboard
      # h.write([0x11, 0x01, 0x09, 0x1F, 0x01] + [0] * 15)

      # this works for mouse
      h.write([0x11, 0x01, 0x0A, 0x1E, 0x01] + [0] * 15)
      h.close()

Location: Marbella, Spain

Remote: Yes

Willing to relocate: No, but willing to travel

Technologies: Python (Django, pandas, etc), Go, Javascript/Typescript, *SQL, ..

Résumé/CV: https://www.linkedin.com/in/jnoehr/

Email: jesper@noehr.org

I'm a software engineer with about 20 years of professional experience, focusing mostly on SaSS products in the tech/fintech space. I previously founded Bitbucket, and I'm the co-founder of Upvest. I've worn many hats, from CEO/CTO to most recently CPO, so I'm open to a wide range of roles, as long as it's something interesting and rewarding.

Apparently their supposed research resulted in a fundamental misunderstanding what an affiliate program actually is, i.e. not the same as "paying for reviews."

Link is dead. This works: https://www.bl.uk/catalogues/illuminatedmanuscripts/record.a...

Arweave | DevOps/SRE | Berlin, San Francisco, New York | Full Time | Remote

Arweave is a new type of storage that backs data with sustainable and perpetual endowments, allowing users and developers to truly store data forever – for the very first time.

As a collectively owned hard drive that never forgets, Arweave allows us to remember and preserve valuable information, apps, and history indefinitely. By preserving history, it prevents others from rewriting it.

Hiring DevOps/SRE folks: https://stackoverflow.com/jobs/350106/devops-arweave-arweave -- feel free to reach out to me directly at jesper@arweave.org

That's like saying cryptography is faulty since if someone encrypted an important document and threw away the key, it would be irrecoverable. That's the point. As for solutions, there are many: use a multi-sig contract with several owners (like a spouse and/or lawyer), or simply leave the seed phrase to be released in your will. The proposed solutions that "may or may not work" are easy to test, I'm not really sure where you get your information.

Do you have a source for this? I can only find reports from "At the Abyss", which are uncorroborated.

I can't speak for everyone, but I'm pretty married to OSX at this point. Using anything else would be too much time invested in setting up the environment as I'm used to, and finding similar applications for everything. Windows 10 is atrocious, and Linux isn't much better.

Cassandra also functions as a time-series database, and does quite well with tick data such as this. Many financial institutions rely on it.

They can vary per user between exchanges, depending on how much volume they have, etc.

This is a bit of a orthogonal argument as this only deals with exchanges directly and never touches the Bitcoin protocol directly. Agreed that the choice of language is an odd one as there's no "high performance"/HFT involved here.

We've never had a breach.

We've had side-by-side diffing for about a year. What the redesign has (apparently) done, is bring forth those features, as we're seeing more and more people discover them today.

We certainly appreciate that, and I personally remember the days of being a small startup. You're in for a wild ride, enjoy it! :)

http://en.wikipedia.org/wiki/Planned_obsolescence

> 2. Bitbucket has a reputation for being a cheap knock off of GitHub for some reason.

The reason for this is very simple: We launched within months of each other, and we look very much alike (how many ways can you skin a DVCS hosting cat?) And then of course there was the whole pointing fingers/attempt to drag through the mud article, that was since removed.

At Atlassian (where Bitbucket now lives), we do something called FedEx (who can ship a product the fastest.) It's a 2-day sprint, where you write up a Shipment Order detailing your crazy idea, giving other people a chance to help you out if they find it interesting. At the end of it, you present what you've done, and everyone votes for a winner.

We just held one a few weeks ago, and several awesome things came out of it. One even shipped the following week: http://blog.bitbucket.org/2011/07/07/redesigned-commits-scre...

It's always a lot of fun, and this, in addition to the 20% time we get, means we get to work on really cool things which sometimes even make it to the public.

They said it: http://twitter.com/RovioMobile/status/53582855015636992

Which Grados are you talking about? The SR60i and SR80i's are about the most comfortable headphone I've ever worn. They're so light and unobtrusive you forget you're wearing them.

Bitbucket was a side project for me, and it was just acquired. I ran it for 2.5 years under my own wing.

Indeed. We won't be seeing any graft vs. host, at the very least.

Duly noted, thanks. :)

I'd love to get some suggestions on what you think would make it a better tracker!

Correct. Our machines don't allow UDP, even. Either the physical machine our VM runs on, or the segment was flooded, which means we couldn't talk outside it.

We're talking UDP flood here, saturating our bandwidth. It never reached our servers, it just ate all the bandwidth on our connection. I guess what Amazon could have done is be quicker in spotting the DDOS and take measures to prevent it.

It was fixed around 4am (GMT+2) last night, with the assistance of Amazon. I'm just going to summarize what happened here:

We were attacked. Massive UDP DDOS. The flood of traffic prevented us from accessing our EBS store with any acceptable speeds, which is what caused everyone to think the problem was between our EC2 and the EBS. Of course this also explains why booting up a new instance and EBS didn't help anything.

Also, it's happening again now, and we're working with Amazon to remedy it once more.

I apologize if that's the tone I'm relaying. I guess I'm just frustrated due to the time it's taking to fix it.

(I don't know why I can't reply to the post below, so I'll reply to myself):

Yes, we did try this, and it produced the same problem.

...As data you can access as a filesystem. S3 is great, but pretending it's a filesystem is going to get you awful performance.

As I said, our data is not lost, we have snapshots and backups, it's sitting right there on the mount, we're just not getting any sort of acceptable throughput. New instances does not fix the problem.

Ironically, we were looking into having S3 as the backend for our data, for scalability/redundancy purposes, but this pretty much puts a stop to that.

When this sort of thing happens, it's very easy to point out all the things you should've done differently. In retrospect, everything's easier.

You can't anticipate everything, and as I've pointed out in another comment here, this one is rather exotic.

Quick summary of what the problem is: We have an EBS volume. It mounts fine, appears fine. The problem is that it's excruciatingly slow. We can't serve data from the volume at any speed, really. Running an "ls" takes over a minute, in a small directory.

All systems are running, everything should be fine, but seeing as we can't read the data fast enough, we've been forced to put a static page explaining what's going on.

Booting a new instance, re-creating the volume from a recent snapshot, doesn't help. The exact same problem persists. Why? We don't know. Amazon's figuring it out.

We're doing everything we can do remedy the problem, but unfortunately right now, that consists of our team drinking coffee to not fall asleep, waiting for the final call from Amazon telling us they've sorted it out.