moreentropy

An IPv6 address has 16 bytes and that's how to store them, period. For parsing / generating a string representation there's RFC5952 and libraries in every language that implement it.

Right. But I doubt that anyone shifting that much traffic just buys 100G internet service to a certain location. If you push out that much you might make use of CDNs, if you consume that much Netflix/Google I guess you meet their criteria and the CDNs talk to you (and place their edge servers in your network).

If you have fiber and the right transceivers, you can run 100Gbit/s over it. If you need that sort of bandwidth, you'll probably do your own peering because just paying for traffic will be obscenely expensive.

Chaos Computer Club's 30c3 conference had a 100G fiber link to downtown Hamburg for a couple of days, still 12k users w/ Gigabit ports and a makeshift datacenter with 10g ports couldn't manage to saturate the link:

https://media.ccc.de/v/30C3_-_5609_-_en_-_saal_6_-_201312301...

The chaos communication camp badge, a full featured SDR: https://rad1o.badge.events.ccc.de/

There was a talk about how this badge was built (non-comercially); it was only possible with most of the chips sponsored and a few people doing pretty much nothing else for months.

Google's business model is about data mining and targeted advertising, not about selling someone's private, identifiable data. That's a big difference.

Actually I trust Google more than anyone else that they do everything they can to keep anyone's private data private. The problem is that that doesn't help when a government agency walks in with a secret court order, be it legitimate or illegitimate.

That's why european end users (and corporations w/ valuable IP) walk away from US based cloud providers or even want to go back to being all self hosted. You can't be 100% sure about your data safety with them and you'll be in deep trouble with your own customers if a data breach - be it lawful under US law, but not under european law - should happen.

Self hosted. Not hosted in the US. Sadly that's increasingly becoming an important aspect for the rest of the world.

Featuring: PHP, obsolete PHP, commercial software and a project that didn't have any commits in over a year.

Want! I have actually used such a converted phone at 31c3. Someone from the Warpzone hackerspace in Münster, DE has built one. He even managed the trickery to drive the original ringer with a simple battery.

> I think for us operations types IPv6 is still too complicated. I mean when someone says "hey, what's the IP of that web server?", saying "192.168.13.129" is easy.

There's a cure for that, it's called DNS. But seriously, building IPv6 networks feels strage for a few hours, after that you just wish IPv4 would disappear because it's clumsy and ambiguous in comparison.

IPv6 leaves so much room to logically arrange your (and the world's) whole network in one namespace without any RFC1918, making routing and firewall configuration really easy and elegant. Soon you will be able to know a system's VLAN/function/location just by looking at certain parts of the address.

IPv6 is (getting more) relevant in parts of the world, because (duh) we're running out of IPv4 addresses. All the backbones and most data centers are already fully IPv6 capable, don't know about cloud providers though. If I rent a bare metal or VPS i can expect full IPv6 connectivity, at least with all the big vendors here in Germany.

We have ISPs here (Unitymedia, one of the largest German cable companies) that have run out of IPv4 and started handing out IPv6-only contrancts to all new customers. Those customers have to access IPv4 resources using DS-Lite /CGN (carrier grade NAT), which is a horrible workaround with a lot of issues. Funny enugh, the same ISPs won't give IPv6 to existing customers because every change will probably lead to increased support costs and make the customer unprofitable.

There was a great talk by a Cisco guy at last year's FOSDEM explaining what to expect with IPv6 and why CGN really, really sucks. Video: https://archive.fosdem.org/2014/schedule/event/no_more_ipv4/

So yes, everyone who serves stuff on the internet should care because you already have or will soon have customers that only have native IPv6 and are best served reliably over IPv6.

For creating decentralized mesh networks, it might help to look at what the freifunk project has done. Freifunk is a community project that builds open mesh networks (mostly in Germany) using cheap (€15-20 range) off the shelf routers. The routers usually provide two wifi networks, an open access point as well as a mesh interface that will mesh with all other access points in range.

The used firmware (called "Gluon") is based on OpenWRT and all open source:

http://gluon.readthedocs.org/en/v2014.3/ https://github.com/freifunk-gluon/gluon

http://freifunk.net/en/

Apart from that, for communicating with systems that have no or only temporary internet access, the pretty ancient UUCP protocol comes to mind:

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

I actually had my first email and news accounts subscribed over the UUCP protocol. The main advantage of UUCP is that it will queue all data destined for a remote system and asynchronously transfer everything when a system is reachable. It is also possible to relay data using multiple hops that are not online at the same time. It was used mostly with dial up systems that were only online during data transfers.

So with UUCP it might be possible to implement a sort of drive-by update where a mobile node (maybe installed in a car) can connect to a local server, exchange incoming/outgoing messages and relay them to the node in the next village when the driver moves on.

Thanks for the explanation.

Actually yes, it's a gut feeling and I think it's justified.

I can totally understand the general idea of stock trading and how it helps both those who have good ideas and need money and those who have the money and invest it according to their taste.

But it's very hard for me to believe that something like HFT where firms go to unbelievable lengths to implement purely technological trading advantages benefit the real economy.

The fact that financial industry as a whole just recently in the 2008/2009 crash and it's aftermath were able to extract obscene amounts of money from our governments (i.e. us) to keep the world's finance system from collapsing makes the suspection that most financial products purely based on a material advantage (be it monetary or technological) are akin to a scam very reasonable.

OK, I guessed I don't have any knowledge to propose a solution here. :)

I still doubt that HFT serves the real economy in any noticable positive way. Does the HFT firm's spending on technology really outweight their effect on the traded stock? And is it aceptable that they earn money purely by gaming the system?

I don't see how HFT does any good for anyone. It adds no real value, and serves no purpose except to shift money from someone else's pockets, not by clever investment and market knowledge but pure technical advantage.

It's a lot like BitCoin, it turns some expensive resource (be it CPU/GPU power or optimized data links) into money, but it doesn't help with earning/generating the money in the first place, so it just extracts it from someone else.

It's a scam and should be banned worldwide. I don't know anything about trading, but I guess by making very small changes (make people hold stock for a few seconds?) you could render the whole HFT industry useless without any negative effects to the real economy.

Regarding the question why CeroWRT, I think this makes perfect sense. DD-WRT ist (afaik) still rooted in the open sourced Linksys firmware, while OpenWRT started from scratch in between. They really do awesome work and have developed a really powerful software platform for embedded devices in general. CeroWRT is based on OpenWRT but is focused on certain important aspects (bufferbloat). So I guess the EFF considers this important and wants to help by giving it some publicity.

This is an awesome talk by OpenWRT developer nbd from 30c3 about the history and future of OpenWRT: https://media.ccc.de/browse/congress/2013/30C3_-_5497_-_en_-...

They also have an overlay for Google maps:

http://www.lightningmaps.org/realtime

This one really deserved downvoting, great job whoever did that :/

Python doesn't have checked exceptions.

For me the most important thing exceptions mean is that they might pop up at any time, with unpredictable types. So as long as I don't have a catch all exception handler wrapped around all code, it might crash at some point.

OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with better error handling. It's the same as putting a try-except catchall around every single call in python, because in python you can never be sure (without reading the source) what kind of exceptions something will throw.

For request based services and something where some big ass operation will either fail in some way (and i don't care where exactly) or be successful, exceptions are fine. If something goes wrong somewhere, log it and reply with HTTP 500. But for servers with data i care about, i most likely want to recover right where the error happened, and actively decide if i want to abort and push the error to the next layer. Not having exceptions makes this more intuitive.

> So we have a python/ruby replacement with very old patterns (I think manual checking errors ie.).

Before using Go, I have always programmed with "modern" languages that use exceptions for error handling. So the concept of only doing manual error handling was new to me, but after a few months of golang I love it now and exceptions in python started to really annoy me.

In Go, I'm forced to do error handling right after every single call that will possibly return an error. While I thought that the resulting code looked ugly and repetitive, the result is a much more focused and intelligent error handling.

If i wanted the same granularity and robustness of error handling in python, I'd have to put a catch all try..except block around every single call .

Exceptions are a good time saver in stateless request based programs (like HTTP/web stuff) where it's sort of accetable if one request fails. I could just not care so much about detailed error handling, the worst that could happen is that i don't catch some error and the wsgi wrapper will catch it and return error 500 to the client. But building daemons in python is just plain painful. If I don't want my program to crash at some point I have to reckon that anything can raise an exception I didn't think of.

Great article, thanks!

If you're bored or not feeling modern today, read http://en.wikipedia.org/wiki/EBCDIC

For practical Python advice (I'm sure this was on hacker news) http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicod... is a great read.

> You wouldn't have to if there were a standard initialisation interface, would you?

My point is, even right now with sysvinit (and aix doesn't use it afair), i have to adapt a init script to every single unix/linux distribution i want to use my software on. At least, if i want to comply with that system's best practice.

With systemd and other init replacements, it's likely a few lines of config file i have to rewrite. Its much less effort to ship or adapt to a few of these than have a init script that works everywhere.

About other unixes: calm down, this is some process that supervises other processes, this is in no way comparable to making libc incompatible. I assume we're talking about servers here that run off the shelf distributions. For (virtual) appliances and embedded devices / firmware everyone will roll their own images with whatever init they're happy with. We don't have any influence on what commercial vendors do. If AIX feels like an 80s system (i know it's modern and powerful at the core) that's IBMs decision, but i don't hear any complaints that Linux distributions don't ship ksh in vi mode as /bin/sh anymore.

So, in this particular market and with the problem at hand, i don't see how and why Linux should wait for the sysvinit replacement that is able to make everyone happy and will magically be adopted by everyone.

And if some day illumos will succeed Linux, I'm sure people will manage to port their 10 lines of service config over.

This is all stuff that needs to be taken care of, on every system. So I'm happy that systemd handles the basics in a sensible way. Why do I as a sysadmin need the choice here? Everything I need is covered by systemd, and in a less painful and more consistent way.

For example, I really do like how systemd-journald takes care of logging, although I don't know why it's not using plaintext log files internally. journald gives me the choice to not log to disk at all, which is nice on embedded systems and my notebook SSD. If i wanted to have logs the old way, i'd just attach a syslogd on journald's socket. With systemd and journald I can have my services log to stderr and everything just works.

I don't have to: * Log to stderr if my service can't start for some reason * THEN daemonize (which is a pain to do in node.js and python, and not possible in golang) * Then switch logging to syslog or my own logfile(s) * Think about logfile rotation * use supervisor or monit to make sure my services stay up

I can't access that site because it returns 500 right now, but: Can we please get over it?

Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain. Edit: I'v read the cached version now, and this assumption turned out wrong. The authors see a need to replace sysvinit.

The amount of bad and inconsistent init scripts, messy PID file handling, makeshift service wrappers, defective daemonization and logging workarounds is so much worse than having one place that will handle those ever repeated tasks.

I love that in recent years Linux (as in distributions) got an attitude and actively push things forward, without losing compatiblity to older software. Apple introduced launchd and nobody complained. We start to rely docker and all sorts of new approaches to manage our services and nobody complains. But init is somehow regarded as the holy cow noone is supposed to touch although everybody agrees it sucks.

Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products, and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.

I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result. How could this get even worse?

Ever heard of Nginx? Would have solved the problem (HTTPS & caching) without one line of code.

I think it's a valid concern. My knowledge of startup culture is very limited, so from what i read here, the usual desired outcome is an "exit" aka getting rich by selling the business. I think that is totally valid for social sites and other freebies, but not for infrastructure services. there is a lot of potential and great ideas in things like hosting, monitoring, crm/helpdesk software etc, and if you're not entering the market with an intention to last, you're actually playing in the hands of tech giants. They're asking a lot of money for crappy and downright ridiculous services (ever worked with e.g. HP Service Center or anything SAP), but give you planning reliability in exchange. With the given startup mindset, you're yielding that market to tech giants.

There are a lot of reasons already discussed, this one is especially famous: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

PHP is not a exceptionally bad platform from a technical perspective, it usually gets the job done, is reliable, easy to operate and performant. But i guess the real reason why so many developers - including me - hate PHP is that plain PHP is pretty boring. It doesn't have opinions on anything and no exciting concepts or language features. Now you can use great frameworks that implement great ideas in PHP, but because PHP has been around for a long time, much of the code out there and still in production is spaghetti code that is no fun to work with and the only option to change that is often a complete rewrite.

This is basically a question I'd like to have answered as well, especially in a b2b setting.

Is it justifiable to use the service of a possibly great startup, knowing that there's a real possibility that it might be sold soon and just be a gear in some other company's product?