HN user

jerdfelt

145 karma

[ my public key: https://keybase.io/jerdfelt; my proof: https://keybase.io/jerdfelt/sigs/Y2JqsCyETlsAKZOwKxY1OWl3-P8uzq1eAQsny2RgRMg ]

Posts0
Comments44
View on HN
No posts found.

You don't have to wait until expiry. Transfers generally add 1 year of service (for most TLDs), so unless you're already at the limit, you can transfer everything now.

It is mentioned in the first paragraph of the README:

shpool is a service that enables session persistence by allowing the creation of named shell sessions owned by shpool so that the session is not lost if the connection drops. shpool can be thought of as a lighter weight alternative to tmux or GNU screen.

The Curse of NixOS 4 years ago

Is there anything that explains the why and how a bit deeper?

As an example, in the video "Packaging a Gem as a Nix derivation", he basically just and copies and pastes another default.nix, changes some strings and mentions he doesn't understand what 'passthrough.updateScript' does, but just changes a string there too.

This doesn't really help me understand Nix.

Location: Redmond, WA

Remote: Yes (have spent the last 6 years working remote)

Willing to relocate: No

Technologies: Python, C, Go, x86 Assembly, Linux, Hypervisors (Xen), Distributed Systems (check my resume for more)

Résumé: http://johannes.erdfelt.com/resume-hn.txt

Email: johannes@erdfelt.com

I've done work from low-level BIOS extensions, to Hypervisor development, to Linux kernel development, to Network Services (DNS, SMTP, DHCP, HTTP, TLS, etc) to high level distributed systems.

I've worked as the first engineer at a startup to large multi-national companies.

I'm generally looking for something in the cloud and/or backend internet services, but I'm open to something new as well.

Unfortunately, Amazon does not appear to keep different sellers products separate in the warehouse. All it takes is one seller sending counterfeit products to the warehouse for their inventory to be contaminated by counterfeits. This makes "fulfilled by Amazon" more risky in some respects.

The 63 character limit on domain name labels in RFC 1034/1035 isn't arbitrary, it's a limitation in the way DNS packets are encoded. The upper two bits of the label length are used for compression of labels in DNS packets.

Without protocol changes, DNS cannot support labels longer than 63 bytes.

However, I agree that validating it is unnecessary.

I noticed this blog post is mostly marketing for their minio software, so I went to check it out (I guess the marketing worked).

I wish there was some documentation available. I understand it's an object store, it implements the S3 API and it's open source. It's hard to figure out much more than that.

This is not the first open source object store (Openstack Swift, Ceph, etc) so it's not clear what differentiates this from other options currently available.

Ignoring the competition, what is the design of it? I'm assuming it can scale out by adding more hosts, but the README doesn't mention how to do that. How does it cope with bit rot? Is this designed for read-mostly data or can it deal with a high percentage of writes effeciently?

I do not have any degree, relevant or not.

Obviously they were happy with my competency since I was offered a job, they just took the path where they used my lack of degree as a negotiating tactic.

Turns out there are plenty of other places that don't care about degrees and offer more money, so I accepted a job somewhere else. It was an easy decision at the time.

The number of hypercalls isn't a good indicator of the attack surface area.

As examples:

There is a full x86 instruction decoder which is technically not part of the hypercall interface. x86 instruction encoding is surprisingly complicated. There was a vulnerability in that code: http://xenbits.xen.org/xsa/advisory-123.html

Handling x86 page tables and all of the various feature bits is also surprisingly complicated. This is part of the hypercall interface, but there was also a vulnerability in that code: http://xenbits.xen.org/xsa/advisory-148.html

In my experience, recruiters that don't name companies will often cut and paste part of the job description from the company. Often a search with some choice phrases from the job description will find the company the recruiter is trying to hide.

Why I don't mock 12 years ago

The Openstack project is a good example of a complex project with complicated testing. Merges are gated on successful test runs of a handful of different tests (unit, integration, etc)

An example of complicated mocking can be seen here:

https://github.com/openstack/nova/blob/master/nova/tests/vir...

In particular, SpawnTestCase.

Disclaimer: While I didn't write this example, I am responsible for some of the other mess

Part of what they do is set up registry locks.

This is different than a registrar lock in that a registrar lock is managed by the registrar (GoDaddy, Tucows, etc) but a registry lock is managed by the registry themselves. It requires personal contact with specific individuals to enable and disable the lock, making attempts to steal domains more difficult (but not impossible since social engineering is still feasible).

I've never used MarkMonitor before, but I did handle the registration for a hugely popular domain at one time. They decided to move to MarkMonitor but in the meantime they requested a registry lock set up on their main domain. This turned out to be very good idea since the registrar at the time was social engineered into changing the credentials for the account (with forged letter head similar to the fastmail.fm attack). The attackers were able to change the nameservers for little used domains but their main domain could not be modified.

I'm not the parent, but I find the nvie.com branching workflow a little complicated.

My experience lies a little bit with the kernel workflow, but heavily with the Openstack workflow, which has large codebases as well.

Both workflows differ from the nvie.com workflow by not needing a 'develop' branch and as a result, needing less merges.

Both Openstack and the Linux kernel use 'master' for development. In the kernel case, changes are reasonably well tested and vetted before they hit 'master' by the use of maintainer branches.

In Openstack, all changes get gated through a variety of unit, functional and integration tests, so they are reasonably well tested as well.

AFAICT, feature and release branches work the same in all three workflows.

I guess both Openstack and the Linux kernel care less about hotfixes since neither run production systems, only their customers do.

In my capacity running a production Openstack system, we apply hotfixes to our release branch and then deploy it from there.

I guess I just really dislike all of the merging that happens in the nvie.com workflow and the extra 'develop' branch as a result. It seems unnecessarily complicated.

Internet Explorer does support SNI since IE7. However Windows XP doesn't even if running IE7 or newer.

That said, we're on our way to a bright SNI filled future, we just have to get over the hump of old versions of Windows and some old mobile devices before it's common enough to be used reliably.

Only reloadable prepaid cards require SSN. Non-reloadable (Gift) prepaid cards don't require an SSN. Some even allow you to set an address for AVS purposes.