145 karma · joined May 29, 2010
https://www.intel.com/content/www/us/en/developer/articles/t...
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.
print >>sys.stderr, "foo"https://nvmexpress.org/new-nvmetm-specification-defines-zone...
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.
https://github.com/lightningnetwork/lnd https://github.com/ElementsProject/lightning https://github.com/ACINQ/eclair https://cdecker.github.io/lightning-integration/
http://blog.sfgate.com/pender/2015/03/25/see-which-fidelity-...
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.
While the implementation is popular, there are alternatives. There is also OpenNTPd, chrony and ntimed for instance.
There are also alternatives to the NTP protocol too, such as PTP and SNTP.
[1]https://www.ietf.org/rfc/rfc5905.txt [2]http://www.ntp.org/
They go out of their way to design and manufacture their own motherboards and equipment[1] to reduce their capital and operational expenses.
While the motherboard and enclosures are probably custom made, the components inside (CPU, memory, etc) are all "commodity".
Without protocol changes, DNS cannot support labels longer than 63 bytes.
However, I agree that validating it is unnecessary.
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?
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.
So I got a job offer from them without a degree, but they certainly did care.
That one case was Google (about 8 years ago) and like an idiot I gave them the paystubs (which matched what I asked for). Their offer was 25% less.
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
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
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.
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.
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.