No luck needed. There's a metric ton of people who just crave well-crafted software. I have a project of that nature now and I am absolutely blown away by the amount of compliments and thank-yous sent our way. It's really quite something.
What I should have said was, "Good luck getting your freelance clients to pay for it." If you're running a software business, which I see you are, with a product that serves a need that people actually have, in a way that they actually need it to be solved, then sure, they'll appreciate craftsmanship.
Because you put the time and attention in before you put a price on it and asked them to pay for it. If you're asking them to value it before you put it in, then you're selling them Fort Knox when all they need is a bank.
It's not just about software, it's about business too. If you want to make software the way you want to make it, you better be willing to sell it yourself.
Freelancing allows you to make software and get paid for it without having to validate the business purpose behind the software. In many cases, the business doesn't need anything fancy, handing them a manifesto isn't going to score you any points.
We are a small Swiss company specializing in design and development of desktop software with a particular focus on polish and quality. Our first product is Bvckup 2 and we are now looking for people to help us grow our product line.
Basically, if you like your C/C++ code light and optimized, all i's dotted and t's crossed, we should talk. There are people out there who recognize and appreciate the software quality as a feature in its own rights. These are our users, this is whom we are after. Come and join us -
1. Senior developer - C/C++/Windows
2. Junior developer - summer internship
3. Marketing & communication expert
Must be legally authorized to work in Switzerland.
libnetsnmp used to make close to a million calloc() calls when responding to a query for a number of CPU sockets on the machine. That was kind of amazing in its sheer brazenness.
Looking for experienced developers to help expanding our existing product into a suite of complimentary products and services (https://bvckup2.com).
--
Basic requirements - Solid C/C++ with a focus on producing lean and efficient code; considertable experience developing and shipping software for the Windows platform.
Good to have - Knowing one's way around Linux, both the development toolchain and the shell; PHP, JS, SQL; people skills for communicating with users.
Nice to have - Embedded and kernel development experience.
Ideally, you should be reasonably comfortable with all elements of a system that allows controlling a Windows app through an externally hosted web interface - from Windows, through the network to the PHP/SQL backend to the HTML/JS web frontend.
--
The company is built around the notion of "doing one simple thing, but doing it really well." This doesn't mean creating simplistic software, but rather having a single primary function that captures one specific user need and then providing a host of supporting features to make things simple and convenient. This is a fairly alien approach on Windows where the software still tends to compete on the length of the feature list first and foremost. However, the good news is that there is a substantial demand for simpler, but better-made software. This is what we do.
Prior to founding Pipemetrics, I was the principal person behind Hamachi VPN service (http://swapped.cc/hamachi).
--
Get in touch - hello-at-pipemetrics.com / alex-at-pipemetrics.com
Additionally, we are considering adding a couple of summer internship positions for EPFL students. If you are at EPFL and the above looks interesting enough, drop me a line.
I'll give you a pointer to an element and you remove it from all containers that it is currently on, in O(1).
The only way to do that is to keep a bunch of iterators in the item itself, which is virtually identical to the intrusive container model except it involves more pointers, more heap allocations and introduces an extra invariant into the data model (the iterator stored in the item must point at a list that actually contains said item). And the only benefit you get for all this pain and suffering is that you don't have to do any "funny" casting via container_of() contraptions.
Point being is that once data items sit in more than one container, intrusive container model generally results in a simpler code that is also more efficient.
Not a dev tool per se, just a general purpose app that may come handy as a part of the development pipeline. Here's the Show HN I made several months ago - https://news.ycombinator.com/item?id=8027405
I went through the whole stack of SMTP RFCs just this week and the takeaway was this.
TCP/25 if you are talking directly to the recipient's mail server,
though it's discouraged if you are not a mail server yourself.
TCP/587 - the same as above, but you are a mail client. In particular,
it's the port for talking to "your" server, which you are tasking with
relaying your email to the destination.
* If you have username/password and want to "login", you want TCP/587.
On the other hand
TCP/465 is a deprecated way of *securing* an SMTP connection.
It's just SMTP over TLS. Deprecated, discouraged, but still widely supported. Functionally it can be either TCP/25 or TCP/587, depending on the setup at the server end.
To secure 25/587, you first speak a bit of SMTP and then initiate the TLS handshake with STARTTLS command. It's all actually really simple. Much simpler than it seems when you are looking at the SMTP configuration UI in a typical mail client :)
And for those that still aren't familiar with TLS yet, think of it as simply SSL but newer and better. So, even though SMTP starts unencrypted the STARTTLS command initiates an encrypted session.
Most mail servers these days use TLS. So, there is a good chance that the email you send with your confidential pricing lists is being sent encrypted over the network. Unfortunately, there really isn't a good way to tell if that happened (at best you can view the mail headers which some servers add headers that show a TLS session was used between mail servers).
Yeah, it's usually possible to tell just from the Received: headers.
For example, here's a (slightly censored) Received: header from a recent e-mail received by my personal mail server:
Received: from mail.foo.com (mail.foo.com [192.0.2.8])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.bar.com (Postfix) with ESMTPS id MX8675309
for <jlgaddis@bar.com>; Mon, 20 Oct 2014 18:31:26 -0400 (EDT)
N.B.: "with ESMTPS".
I'm sure that others will correct me if I'm wrong (please do!) and this almost certainly isn't foolproof (and I'm likely missing some and there are probably exceptions as well), but just from my own observations: "ESMTP" refers to a standard, unencrypted SMTP session (25/TCP), "ESMTPS" to an SMTP session where STARTTLS was used (25/TCP), "ASMTP" to an authenticated SMTP session where "full" SSL/TLS was used (e.g. 465/TCP), and "ESMTPSA" to an authenticated SMTP session where STARTTLS was used.
Of course, you can't see these on any outgoing messages you send, only incoming mail.
To add just a little more to your great summary or perhaps clarify a bit ...
MTA to MTA (mail server to mail server) traffic will use 25/TCP (with a very few "special case" exceptions).
MUAs (i.e. desktop clients) -- Outlook, Thunderbird, etc. -- should almost always use 587/TCP (the "submission" ports) and use authentication. This is almost certainly the case if your ISP is not also your e-mail provider.
ISPs will often allow their own users (or, more correctly, hosts on their own IP networks) to send mail through their own mail servers on 25/TCP without authentication, but not always. If not, use 587/TCP and authentication.
Many ISPs will block traffic destined for 25/TCP to hosts outside of their network, except from their own mail servers. In these cases, you'll need to either use your ISP's mail servers as relay hosts or send mail via port 587/TCP on your e-mail provider's mail servers (and you'll have to authenticate, of course).
Also, it is entirely possible that your ISP's "dynamic" IP addresses have been blacklisted by popular third party blacklists, e.g. the Spamhaus PBL [0] or Zen [1] lists (Zen incorporates the PBL and others into a single list). If the remote mail server you're attempting to connect to uses these RBLs, you'll be unable to send mail via that server, even if your ISP isn't blocking 25/TCP outbound (which is becoming more and more popular nowadays).
As latitude mentioned, the primary difference between 465/TCP (which, again, is deprecated but still fairly widely used) and 587/TCP is in the use of TLS. 587/TCP starts off as "plain text" and switches to "encrypted mode" upon the client's issuance of the "STARTTLS" command while with 465/TCP the entire conversation is encrypted (such as with HTTPS). Both will require authentication (unless, as mentioned above, you are using your ISP's own servers and they allow unauthenticated relaying from their own IP space) but encryption (TLS) is (usually) optional with 587/TCP.
For sake of completeness, on the "mail receiving" side, POP3 and IMAP operate similarly. The "regular" POP3 (110/TCP) and IMAP (143/TCP) ports often (but not always) support "STARTTLS" (converting the "plain text" connection to an "encrypted" one) while the POP3S (995/TCP) and IMAPS (993/TCP) ports are fully encrypted from start to finish (again, such as with HTTPS).
I run my own personal mail servers as well as those at my employer (an ISP) and the biggest (e-mail related) issue we seem to have is with "off-net" customers who are trying to send mail -- typically this is a business customer (or a business customer's employee) who sets up their mail client on a laptop while on our network (where authentication is optional) and then attempts to send mail via our server while outside of our network but is denied due to either lack of authentication or port 25/TCP being blocked. This is easily solved by reconfiguring the client to use SMTP authentication and/or 587/TCP.
If you're responsible for managing end users' mail clients, just set them up to use 587/TCP, STARTTLS, and authentication from the start and save yourself some trouble down the road.
You never have to pay anything, and you can keep using
Ello forever, for free. By choosing to buy a feature now
and then for a very small amount of money you support
our work and help us make Ello better and better.
This is way too generous and altruistic to be practical. They obviously mean well, but this is effectively a donation-based model and it very rarely works in practice.
What I think they should do is to offer personal accounts for free and charge for enterprise presence. I know a handful of people who use Facebook and Twitter in read-only mode and who follow just the companies. They effectively use social networks as a news feed of product updates, coupons, deals, discounts, etc. Moreover, they explicitly seek out the companies and follow them. If you think about it, it's an insane arrangement - you have people opting in to hear to what you have to say. This is valuable, this is something worth paying for and it keeps the network free for the individuals.
You don't need to reinvent TCP. You can simply put TCP over UDP. Works like magic :)
TCP hole punching works just fine in practice, but it's certainly a part of the "long tail" of empirical hacks that allow bumping NAT traversal rates into 95+% range. Detecting NATs that decrement ports is another. Ports that are incremented/decremented by more than 1 is yet another. And there's also UPnP that gives you another percent or so.
I was doing this as a part of the Hamachi project [0], almost 10 years ago, and this long tail was absolutely instrumental to being able to serve hundreds of thousands of clients off just few measly Dell servers for $300/mo in hosting costs.
Its somewhat OT, but thanks for Hamachi! It made many a late night gaming session possible in my teens and early twenties, and was always an astoundingly simple piece of software to use considering everything it did.
Cool to get a ping from Hamachi's author. I deliberately did not use Hamachi while designing ZeroTier since I didn't want to pollute my headspace with something so similar. :)
ZeroTier right now is sort of an OSS Hamachi, since I figured this would be a good starting application, but I've got different longer-term goals in mind. (Won't be abandoning that application though.)
No luck needed. There's a metric ton of people who just crave well-crafted software. I have a project of that nature now and I am absolutely blown away by the amount of compliments and thank-yous sent our way. It's really quite something.