uuid_to_string

Aren't a couple of those "less than objective" judges coming up on retirement?

What then?

Interesting opinion.

The "overhead" I'm concerned with is based in hardware, not my own creativity.

When I install Python I get about 14MB of stuff.

The interpreter is about 8K.

The libpython shared library is about 1.5MB.

If what you are referring to as the standard library is in that 1.5MB, then disregard my comment on LOC.

If it's in that remaining 12MB or so of stuff, then I'm wondering if LOC counts should include what is in there that is required for these programs to run.

Look at it this way. If I download 12MB of code and then I write 500 lines, does that mean I am a master of writing small, compact code?

Sure, if you ignore the 12MB I had to download first.

I'm not singling out Python. Perl, Ruby, etc. are equally large.

The point is you are downloading 1000's of LOC to enable you to write "short" programs.

Nothing wrong with that. But those 12MB that were needed beforehand... should we just ignore all that when we count LOC?

Maybe one has to do embedded work to have an appreciation for memory and storage limitations and thus the sheer size of these scripting libraries.

The standard libraries count as an external library.

Why wouldn't they?

So who should we entrust with protecting our communications over the open Internet?

The US defense contractor and the reclusive gentleman in the UK whose code (for whatever reasons) has a rather poor security record,

or

the math professor whose code (qmail, daemontools, djbdns, etc.) generally has an excellent security record?

Who enforces better quality control?

Does that matter?

Or maybe we should be asking how much these men are paid? (As are the journalists and their readers.)

We know from the statements of the US Steve that the UK Steve does not get paid much for his work.

Maybe it's really not about the money?

Nevermind. I'm sure the journalists have it right.

How many LOC in the libraries used to be able to write the implementation in 500 lines of Python?

Why not include some experiments with Lua and lpeg?

It would probably be faster than Java or Python.

And arguably Lua is easier to learn.

Maybe the work required (one-time cost) would be rewarded with significant gains.

I'm guessing the downvoters have no clue what TAP is or why it is relevant to peer-to-peer.

Either that or they just think this is some critique of their beloved Apple.

I'm referring to the TUN/TAP driver.

All BSD's have it (/dev/tap).

And to easily do encapsulation, which is very handy for VPNs and peer-to-peer, you need it.

OSX has it. iOS does not.

So, downvoters, why is TAP missing from iOS?

Why is iOS crippled? Or "castrated" to use the parent's terminology.

I've got peer-to-peer that relies on TAP. Not a problem with any BSD or Linux or even OSX.

The exception is iOS. Why?

Last time I checked iOS still lacks a TAP device.

Castration indeed.

(First stage bootloader)

Yes, I know that.

I have yet to find a device that meets all my requirements (some of which I did not mention).

In RPI's favor I will say that 1. it is not "in development" but is "on sale" and 2. it does not come with Linux preinstalled. Letting users choose their own OS and not limiting the choices is a start in the right direction. There is of course further to go. Alas, it does not stop at the bootloader.

So, where do you recommend purchasing the device(s) you mentioned when they eventually go on sale?

As soon as they have something that boots BSD, where starting the graphics layer is optional and it has decent networking, I will definitely purchase one of these. I wouldn't mind a little FORTH, too.

Godspeed, OpenMoko.

Yes, this is a good suggestion. Time will tell. I prefer BSD and this is potentially a candidate.

For now, I'm investing my time in my RPi.

   "It's an interesting project but practically speaking $100 (no contract) can already buy a pretty good smartphone these days... and one with a more "unofficially open" SoC too."

Is it OS agnostic?

I would actually be willing to pay more than the going rate for a "smartphone" that that allowed me to use my own bootloader and my own choice of OS, and one with no ties to search engine ad sales companies or the like.

I just want a handheld computer with a decent enclosure and which can be controlled with time-tested, open source drivers.

It does not need to have impressive specs, just a small form factor and easy to control with any open source OS.

If it can make phone calls, all the better.

No, you said that. I said that having email so closely coupled to DNS is part if the problem.

I'm not sure why you would have to remember IP addresses. We routinely "dial" telephone numbers by selecting from a list of contacts. IP addresses are approximately the same length as telephone numbers. The folk wisdom is that people can remember about 7 digits. But even if you disagree on all of this, what does that have to do with letting someone else control our email? The issue here is control, not whether we use names or numbers or something else when we enter the address of the recipient.

The nonportability of IP addresses is a problem in its own right, but I don't see the relevance here. Again, you are trying to engage me in a debate over domain names versus IP numbers. Perhaps that is an interesting issue, but here I am interested only in the issue of control over email (and because email and DNS have been coupled together, DNS). And that is what the OP is interested in as well.

I said that email and DNS are closely linked and this makes email more challenging for any user to control. 1. Because it complicates the setup and 2. because DNS as we currently accept it is controlled by third parties.

You are trying to suggest that I am advocating against having email addresses that use names instead of numbers. I am not.

If email is linked to DNS, and someone else controls DNS, then you cannot control email.

If you disagree with the preceding statement then please explain.

Thank you for being honest.

But I am actually referring to something different: hosting your own mailserver.

So when I say "set up DNS" I mean set up a DNS server, not simply an MX record. This allows you to create your own domain names and hence email addresses. As I said above, these email addresses are valid so long as you and the recpipient use the same DNS root (e.g., ICANN's root in the case of the public internet).

As bad as things are in terms of the relative difficulty of setup, I think there are defenders of the status quo for email and I imagine this explains how I could be downvoted for my comment.

Don't get me wrong, I love email. It is the reliance on others to handle 100% of it that troubles me. It is purely a control issue.

Are we discussing control of email, or aesthetics of email?

If you want to use names instead of numbers, then you can do that. You and your recipient must use the same DNS root.

OpenBSD has to be commended for executing on a simple idea that sadly few developers ever adopt:

You can make software more valuable by taking things out.

Part of the problem is that many years ago certain people decided it would be a good idea to tightly couple email to domain names (DNS). Previously email needed only IP addresses to work.

The result is that now when you are configuring SMTP you have to also configure DNS. That means more things that can go wrong, and more things to check as you are setting things up.

It also means you may need to pay a fee for a domain name. This is because we all submit to the notion of an ICANN root and commercial registrars selling (renting) names that cost nothing to create. Thus email is not solely under your control. You generally have to play the ICANN DNS game, only because your email recipients are playing. Nothing stops anyone from running their own root though. And this is what is done with private DNS inside organizations.

And then, as if that DNS complication was not already enough to take control of email away from you, you have various schemes trying to prevent spam that discriminate for or against mail you send based on IP address and domain name.

Can you operate email without DNS? Technically yes. There was a time before DNS, and email worked just fine. Practically speaking, today you need DNS, whether it's under ICANN's root or your own.

All this hassle steers you to just accept third party email hosting. Profiting from this arrangement has become a career for many a man. And with "the cloud" many are hoping to cash in yet again, as organizations who once ran controlled own email feel pressured to let a cloud computing vendor control it for them.

The fact that all this third party control makes warrantless search and surveillance so easy is but one side effect. Centralising hundreds and thousands of accounts in third parties make the spammer's job easier, too. If you think about it, there are many unwanted side effects of centralizing email. When every sender and recipient are connected directly to each other via a network, why would you want to prevent them from sending messages to each other directly?

With the constant connectivity and bandwidth we have today in many places, the centralisation and outsourcing of email is baffling to me... it is nonsensical... until you remember how much of a PITA it is setting up email.:)

It's no wonder we let third parties handle it. Is this PITA by design? Who cares? Let's just fix it. More of these projects should exist. Or made public (I imagine many of these are personal setups now being released for public use). I have my own that uses qmail.

For per packet encryption.

For authentication, there is CurveCP.

People seem confident with OpenSSH's authentication mechanism. Why not use that?

At some point one has to trust that the IP address one is sending/retrieving data to/from is the correct one. That's easier said than done if some host wants to keep changing its IP address every few days.

The SSL PKI scheme (the SSL approach to authentication), as implemented for public websites, is not much of a confidence-builder, IMO. Opinions may differ.

If websites maintained consistent IP addresses and we could authenticate these machines using OpenSSH keys, I would be more willing to believe we could verify their "authenticity".

How did you reach this conclusion?

At least with devices running iOS, if you let the charge drop to zero, and it loses its cached network settings, and then when you try to reconnect to your home wifi router, it will look for a file called

library/test/success.html at www.apple.com

which contains one line: Success.

If that file is missing, you will not be allowed to connect to your own home LAN, because Apple thinks you are behind a "captive portal". I redirect *.apple.com to stop iAd, ntp and other Apple crap even when I'm connected to the internet, so unlike the OP, this is a problem even when www.apple.com is not down for maintenance.

One solution is to redirect www.apple.com to your own httpd serving a local copy of /library/test/success.html.

In short, you are wrong. Redirect apple.com comains to your own httpd and read your logs.

There is lots of dialing home coming from iOS and indeed some of it will affect your ability to read content.

Our current testing utilities are relatively small and compile with modest amounts of RAM. Hobbit's netcat, WR Stevens' sock, etc.

We have security auditing rules that require us to compile the programs we run from source. We prefer small programs as they are easier to audit.

Does anyone know how much RAM is required to compile Chromium?

Can it be done on a laptop?

You are correct. They mentioned Heartbleed and the software that is responsible for it.

Chances are, you're already running one.

If you have a smartphone, it allows the carrier (=client) to access the device (=server) remotely.

Same for cable modems.

Maybe you also have a Wifi router. It is listening for HTTP requests because it has a "Web GUI". It is thus a web server, among other things. Maybe it also has a "backdoor" for remote login as reports continue to show this is common.

The idea is your devices are listening for incoming connections and they have data stores to serve on demand.

You may disagree but I would call these servers.

Many people manage to setup Wifi routers at home.

And with a modem or smartphone, there is almost no setup. You just turn it on and it starts serving.

So, I'd argue that "running your own server" is actually something anyone can do.

Maybe the real barrier to "running your own server" is only just confusion over terminology.

"It doesn't scale!"

Who said it needed to scale?

How many Facebook friends does the average user have?

Do these these networks need to be larger than that?

If users want larger networks they can bridge their VLAN's.

"I don't like your logo!"

I'm using a text-only browser so I really don't care what your logo looks like.

Keep up the good work and ignore the critics.

Suggestion: Make the crypto fungible, so if a user wants to use a different library, e.g., NaCl, they can.

As you know, OpenVPN cannot do what n2n can do.

Someone has to run an OpenVPN server. Everyone on the network has to trust that server.

And connections between network participants are not peer to peer.

With OpenVPN and most other VPN's, if I'm not mistaken, each person's traffic passes through a central point: some VPN server/appliance.

This is a major difference and has its own set of security implications.

By "you" do you mean me, personally?

The servers I use do not have bash installed by default.

The only time I use it is when I am forced to by an installation script.

I install bash on an as needed basis, and when I'm done using it, I uninstall it. I just have no need for it otherwise.

What is the shell on Android? Is it bash?

What do you use for things that matter?

Do you have something else to create L2 overlays that is more secure?

http://curveprotect.org/howto-vpn.html

What if you invested in learning a shell that was installed on all servers you lack control over?

What if you invested in learning POSIX sh?

Wouldn't your scripts and one liners written in POSIX sh work in zsh, bash, etc.?

You could be comfortable on any server, no matter what the shell.

Even servers that default to tcsh still have /bin/sh.

The author is a systems engineer at Cloudflare.

Might that be because OpenVPN uses OpenSSL?

Or maybe because OpenVPN is less auditable relative to something like SigmaVPN?