Shine on, Terry, you crazy diamond.
If nothing else, TempleOS is a testament to how much one programmer can accomplish absent feedback or collaboration from others. For better or worse.
545 karma · joined October 1, 2013
If nothing else, TempleOS is a testament to how much one programmer can accomplish absent feedback or collaboration from others. For better or worse.
(The rest of this post isn't aimed at you, chimeracoder - but you've made an argument I've heard a few times, and I'd like to address it at length, because this is where systemd discussions usually devolve into namecalling instead of actual discussion.)
Thinking of systemd utilities like unused kernel drivers - just harmless bits occupying disk space and never used until loaded - is simply an incorrect analogy. A client of mine is running systemd in prod, and I'm managing their system - so when I tell you this, what I'm saying is "whoever explained either isn't running systemd in prod on multiple machines, or is having a wildly different experience than I am." Ask whoever explained this to you if they are running systemd in prod! I would love to be wrong about this!
I feel like I hear this explanation (excuse?) fairly often, so instead of setting up a straw man, lemme flip the script here:
Could someone - anyone! - please point out a single distro or OSS project that a) makes use of systemd and b) doesn't end up building the same exact monolithic init.d re-implementation as everyone else running systemd?
Systemd could potentially be used as a suite of independent tools, kinda, I guess - but that's not what the devs are aiming for from what I can tell, and I've never seen - or even heard discussion about - systemd being used in practice as anything besides a monolithic init.d replacement. Most arguments to the contrary fall apart really quickly, with a simple question:
"How and why would you actually build this theoretical pick-your-own-utils-totally-not-a-monolith thing you're describing? Please show your work. Extra credit: explain why no one else appears to have attempted this, outside of the thought experiment that I've just proposed to you".
My guess is, like it or not, I'm going to be stuck using systemd-resolve (the DNS resolver) and systemd-timesync (the NTPD replacement), I'm guessing, because I want to use systemd-network, and the best case scenario is that my old ntpd and nsd daemons are going to have some weird issue working properly with systemd-network. What weird issue? Well, those old daemons had some quirk or other that really should have been fixed for interoperability's sake, and mumble mumble DBus won't connect for some esoteric reason, so.... they'll still "work", but the systemd-* replacement we've written works so much more cleanly and with less random flaky bugs , and using them will stop that weird hanging issue you're seeing, so....
Ugh.
(Again, sorry chimeracoder for the comment hijack. I have a lot of systemd angst, apparently.)
....and not to kick it off myself, especially as the devolution from reasoned argument to straight-up whining seems to happen often in discussion about systemd but: ugh, really? My init system now needs a DNS resolver - sorry, from the article "a caching DNS stub resolver and a complete LLMNR name resolution implementation" - to be baked into it?
http://superuser.com/questions/785072/e-fail-0x80004005-when...
Btw, thanks for the link! I suspect more than a few 6500 linecards that I've seen die in years past were due to something similar, as opposed to what we'd previously assumed to be the root cause - either damage in transit or "cosmic rays" ;)
Hmm, I just realized, if enough peers with 6500s/7200s have flapping BGP sessions with their upstreams, that would be a problem even for upstreams with beefier routers and more available TCAM - too many flapping peers == too many dampened routes == lots of "fun" resetting BGP sessions and coordinating with peers. Yipes.
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-...
Takeaways: a) 512K routes isn't necessarily a hardware limitation, it's the default TCAM allocation for IPv4 and B) most people most of the time don't need their routers to take a full BGP feeds worth of routes - and I hope those that do aren't running 6500's in Q3 2014 ;)
Assuming a Cisco 6500/7200 model router - the one most commonly affected by this issue - there's a certain amount of TCAM available by default for IPv4 routing, IPv6 routes, and multicast. By default, IPv4 only gets 512K routes. You can re-allocate more space to IPv4, but there's a potential cost... given the current rate of IPv6 adoption though, you could say that cost would be negligible for most people.
More details here: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-...
(The question I have is, why are people with these routers taking a full BGP feed of 512K routes? I'd assume that 90% of the time a default route will do, or even just default to your transit + their direct peer routes...)
Many, many ISPs, hosting and content providers use routers with this limitation. So their customers are going to be impacted, in some indeterminable way.
(Network geeks - I've glossed over a point or two, I know. Caveat lector.)
Assuming you have rights to transfer the block, the current going rate for RIPE addresses is between 10 and 20 dollars per IP, depending on the size of the block and the buyer (e.g. APNIC buyers have a higher level of demand than ARIN, and an inter-RIR transfer to either is about the same amount of hassle).
Minus side is that a broker will take 25% of the cut at least. There's a smaller market for non-brokered transaction, but you'll need help navigating those waters.
Let me know if you have any more questions. Also, this is just a /24, yes? Just want to make sure I'm not misinterpreting 'class C', it's been a long time since I've heard that term and I'm way used to CIDR now. At the moment a /24 might not be worth the hassle of selling, leasing it out for temporary profit on a month by month basis and then selling when the market gets even tighter might be a better option.
You've made an argument to authority with your lead-off sentence of "that's not how businessses are run" and a no true scotsman argument with "no sane person running a business", and then tied it up with an absurdo ad reductum analogy about security guards.
There are plenty of shops that I've personally worked with, and many more that I've read about here on HN that do daytime maintenance / make potentially breaking changes to production. I'd be willing to bet Heroku does a mix of day and night time scheduled maintenances, with scheduling determined by a reasoned analysis of the risks and potential for an outage.
If you think a 1 AM maintenance window helps anything, I'd bet you've never seen the sunlight come up as you staggered out of a datacenter 10 hours after your "midnight maintenance" went south, and no one with an optical light meter to help you trace down a dodgy fiber run was awakee at your transit provider, so you had to wait until the first shops opened to buy your own...
...ok, maybe I'm a little bitter. What I'm getting at is, a 1 PM outage - although more customer facing than a 1 AM outage - will almost definitely be resolved faster, because resources outside of the engineers performing the maintenance are in abundance at 1 PM and not 1 AM.
Bonus points: your engineers will not be zombies for the next three days, and that's important both for post-outage work and to make sure everyone stays sharp for the potential "bounce outage" (e.g. your first outage was the core router dying, the second will hit the same week when your new replacement core router's slightly upgraded IOS version causes a BGP flap under certain conditions that don't arise until a good 48 hours after you mail out your customer outage report....)
That might sound trivial, but at scale - if you have tons of engineers and are doing tons of maintenance all the time - it's actually really important, at least IMHO.
(Quick, take a guess - how many Heroku daytime maintenances do you think went off without a hitch that you've never heard of?)
P.S. what time zone are you in? I assume your time zone's 1 AM is the important one, so someone else on the other side of the country is going to either have a late evening or early morning maintenance window..... ;)
1) I'm not annoyed that Steve's built a competing product. That would be like the developers of Squid being annoyed that Varnish exists, or lighttpd and Nginx, or.... you get the picture. Competition in the free market and especially amongst software providers is good and healthy, and saying otherwise is tantamount to saying that software is sacred. That way lies patent madness. Besides, LuaDNS and I'm sure others have similar products. I was actually really excited about this, as it validates our market, theoretically - until I recognized the name and visited the site.
2) I'm furious that Steve blogged about us, mailed us directly - so he damn sure knows about us and our product - and then directly lifted our copy and messaging, and is now presenting this as an original concept on a Show HN post. That's where this all falls apart. Just - not cool, buddy. Not. Cool.
1) On April 19th, Steve wrote this blog post mentioning us, Namecast: http://blog.steve.org.uk/i_was_beaten_to_the_punch__but_felt...
2) At around the same time Steve sent me a personal email doing market research on the concept of Git-backed DNS. I didn't respond because, well, it was a bit of a clunky first way to ping someone. Still no problem, though - who hasn't sent a random stranger an awkward email before, right?
3) He then decided to build a competing product - and steal our messaging?! Seriously, go to http://www.namecast.net right now, check out our above the fold copy, and then check out dns-api.com. "Imagine if updating your DNS records was as easy as running "git push"." Really, Steve? Really?
This is where things go in my mind from "hey, two DNS guys had the same idea about Git and DNS, neat!" to "this dude can't create his own ideas so has decided to steal our copy and cargo cult copy our product."
Luckily Steve isn't very good at DNS or handling traffic, so his servers have fallen down and people are complaining about his feature set, so instead of complaining too hard:
For those of you who want a provider who's site won't fall over after a tiny crush of HN traffic, check out http://www.namecast.net.
We've also got working SRV, TXT and alias records - some of you have noticed dns-api.com doesn't - as well as geoIP and native IPv6 amongst other things, and as good members of the open source community, we're contributors to the open source geodns project (written in Go by Ask Bjorn Hansen, it powers the global NTP pool - so if you've got software that talks to pool.ntp.org, like say, ntpdate, it's talking to a server running geodns.)
mic drop
--afsheenb
If I run
dig -t AAAA news.ycombinator.com
I don't get any records returned, unlike every other CF hosted site that I tested. HTTP headers and NS records confirm CloudFlare is running things, just not offering v6 addresses...
If you stopped etcd on all your CoreOS nodes, installed consul, and had all of your CoreOS systemd units register with consul (say, with an ExecStartPre step), you'd technically be 'running CoreOS with Consul' - but fleet would be just straight up broken without etcd, meaning there'd be no way to submit units to different nodes in your cluster, or view logs, or really manage the cluster at all.
Looking at the fleet source code (https://github.com/coreos/fleet), it looks like swapping out etcd for consul would take a lot more effort than 'sed -i -e 's/etcd/consul/g' *.go'. You'd essentially have to do a rewrite of fleet from scratch.
cat /usr/lib64/systemd/system/multi-user.target.wants/locksmithd.service [Unit] Description=Cluster reboot manager Requires=update-engine.service After=update-engine.service
[Service] EnvironmentFile=-/usr/share/coreos/update.conf EnvironmentFile=-/etc/coreos/update.conf ExecStart=/usr/lib/locksmith/locksmithd Restart=always RestartSec=10s
[Install] WantedBy=multi-user.target
...and also a new locksmithctl binary that has options for setting and unsetting locks among other things. I guess you could create a systemd unit that unlocks any set lock, and run it 10 minutes after boot with a systemd timer, as a start.
Comcast will get paid by their customers as long as the routes they pass traffic through are 'good enough'. They have a (near) monopoly on the last mile in many markets, so 'good enough' can mean both 'barely working' and 'better than any other option you've got' at the same time.
So, you're right, but so is the parent: Comcast has no financial incentive to provide any more than just enough bandwidth to keep you from calling the support line to complain or cancelling your contract in frustration.
Where's the rest of customer revenue going, if not towards network upgrades? Well, let's just say the Comcast Center (http://archrecord.construction.com/projects/bts/archives/off...) ain't paying for itself...
https://developer.github.com/v3/oauth/#scopes
There just isn't much granularity there - GitHub OAuth enabled integrations that need repository access can jump from having no specified scope - which grants access to your profile data only - to scope 'public_repo', which grants read-write access to all the data you've listed above, in any public repository, and then to scope 'repo', which grants the same for public and private repos.
It's a shame, because most GitHub integrations I've seen seem to need enough access to just list your repositories (public and private) and ask your permission to enable a webhook on a given repo at your request.
There's no way to do that with GitHub OAuth at the moment without asking for the 'repo' scope, and along with it a whole load of privileges that most people just can't / won't feel comfortable granting.
Stack: Amazon Web Services, Docker, CoreOS / Debian / CentOS, Puppet, Ansible, Chef, HAProxy, nginx, Varnish, and in general weird and neat unix-type things.
Resume: http://github.com/afsheenb
Contact: ylloffehillu-8514@yopmail.com (I'll respond with a proper address
Overview: I do linux-y and devops-y things. Let's chat.
OP: What are the technical limitations that stop builds from working inside a single Dockerfile? Just curious.
Question for anyone from GH who's reading this - will there be documentation released for how to integrate with GH Enterprise? I imagine there are some implementation details (e.g. OAuth access) that differ between regular GH and a GH enterprise install.
Mine was originally one of the first comments on the article, and it turns out lots of people have had questions about ALIAS records since then, because "what's an ALIAS record?". (If you read the comments, I've actually been advertising for our "competitors" if anything - I think I got DNSMadeEasy a sale today ;).