latitude

It'd be interesting to see if this is going to work on scale... but I don't think it will. There's something inherently wrong with the idea of a machine bossing people around.

I have the same reservations as eps. It's not how Chocolatey works, it is how it's administered.

With Steam and Microsoft I can be reasonably certain that I will not be getting an infected update. With Chocolatey, being a smaller entity, I have to assume the opposite until proven otherwise. It may work, it may have wide support, but none of it matters, because it may get me screwed. Bluntly put, Chocolatey is simply not trustworthy.

Yup, exactly.

It used AuthentiCode executable signing to bind VeriSign's timestamps to the documents. Basically, this allows for an unlimited use of VeriSign's mature and robust timestamping infrastructure for a cost of a single signing certificate ($150/year or thereabouts). Not to pat myself on the back, but I think it was nothing short of ingenious :)

I killed almost a year on a similar project and it flopped majestically.

I even worked out how to do the whole verification part that it works out of the box without the need for any software or 3rd party service. You just needed a Windows box. Still that made no difference whatsoever, because ultimately selling this sort of service is like selling insurance. You have to force people to think about bad things that could happen in order to make a sale, and that's just not everyone's cup 'o tea.

Postmortem - http://swapped.cc/certtime

I don't know why you are in gray, but that's a valid point. I too had to switch to IE to get fonts.net to release the font files.

The site looks great. Not sure how it performs against your target audience, but it looks great. A couple of nitpicks though -

1. "Sign up for free 30..." button at the bottom of the home page should really be white/on/blue to match "Try depot for free" button styling in the main section.

2. "Keep up to date" is too dark and doesn't look like a hint, more like a message. Also "Submit" button is 4-5 px taller than the input field (Firefox), so altogether it looks sloppy. And it should too be white-on-blue.

PS. Tungsten doesn't look all that great on Windows and even on Mac it has this seriously wobbly baseline. Just look at the "Ingeniously simple ..." at the top of the page and focus on the bottom of it. It works against the look and feel that you are after.

There's some bias, no doubt, and the sample is barely representative. But the thing is that there's lots of new hardware, like Thinkpads, that ships pre-configured with higher DPI. Drop by drop, but this will tilt the scales .. if it hasn't already.

1-2% is a bit low.

I actually tested this several months ago for one my projects and it was about 5% (on a sample of few hundreds). That's a very respectable 1 in 20. Not that I disagree with your ROI point, it's just that playing well with non-default DPIs becomes progressively more important now.

All sizes in dialog templates are indeed specified in "dialog units", which are based on the metrics of the dialog's font. So in theory if you are to double the font size, all dialog elements would just double in size and all will be well.

In practice, this is not sufficiently accurate to accommodate text size differences when going from one font/size to another. It's just too crude.

For example - http://imgur.com/STtd8OQ

  Top is SegoeUI/9pt, standard for DPI of 96.
  Middle is SegoeUI/10pt, standard for DPI of 125.
  Bottom is Tahoma/8pt, standard for XP at 96.

See how bottom two trim "practice"? That shouldn't be happening, but it does.

Just to be clear - supporting High-DPI on Windows is not as simple as adding scaled up resources. Instead, it is an absolutely royal pain.

For one, you can't just throw hires bitmaps into a resource section of .exe and expect them to magically work. There needs to be code that looks at current DPI and picks matching bitmap.

For two, standard DPI levels are 96, 120, 144 and 192, but guess what? All other values in between and above 192 are game too. In fact, there's a nice little slider in the Control Panel that encourages you to put it somewhere in between. This means that your code either needs to rescale bitmaps to match these odd DPIs or use the largest one that fits. In either case the result will look like butt.

For three - the dialog layout. If your dialogs have text that's longer than 3-4 words, the chances are that it will either overflow, underflow or wrap differently under different DPIs. This in turn means that you need to test dialog appearance with at least 4 different font sizes and Tahoma 8px for Windows XP. Do you know how hard it is to word a longish sentence so that it would fill about the same space with all 5 combinations? Really damn hard and very time consuming.

But wait! There's more.

Every app icon needs to exist in at least 9 sizes, like so - http://imgur.com/5Pe2ZV0 - and this would still miss some cases where Windows will scale an arbitrary chosen icon image and use it.

It really is a mess. However this is not something unexpected if you've been writing for Windows for a while. This mess is a routine.

Alternatively -

  int send_fd(int conn, int fd_to_send)
  {
  	struct msghdr msg = { 0 };
  	struct cmsghdr * hdr;
  	char buf[CMSG_SPACE(sizeof(int))];
  
  	msg.msg_control = buf;
  	msg.msg_controllen = sizeof(buf);
  
  	hdr = CMSG_FIRSTHDR(&msg);
  	hdr->cmsg_len = CMSG_LEN(sizeof(int));
  	hdr->cmsg_level = SOL_SOCKET;
  	hdr->cmsg_type = SCM_RIGHTS;
  	*(int*)CMSG_DATA(hdr) = fd_to_send;
  
  	return sendmsg(conn, &msg, 0);
  }

To those wondering why and when this is needed - it is useful for cases when your primary process lacks rights required to open a file or a device (!). So another, privileged process does the open on its behalf and sends the resulting file descriptor to the primary process for processing.

You are asserting a made-up argument. Having an active public project behind a logo is not a necessary condition for not re-purposing the logo for another project. This particular concept just happens to be taken.

Every good logo is trivial in retrospect, it's finding a strong concept that's a bitch. I looked at /gd/ thread and virtually all of it revolves around shaping a keyhole this way or that way. Then suddenly someone says - "Here, done". Turning an empty space into a chat bubble requires a step up, it's an altogether stronger and more complex concept. It is possible that another person came up with it independently, but also consider that with all the variety of secure messaging apps no one had thought of it before 2012. It's not an easy concept to stumble upon.

(edit) This is getting meta. It is plenty obvious that Tox fellas think they are in the clear and it's OK to recycle an existing logo. I think that it's not. That's hard to reconcile.

> As such, why not just leave the logo of Tox in peace?

I have plans for it. It wasn't just an idle doodle.

> Your basically claiming

I am not claiming this, this is how things work in the logo design industry. There are of course copyrights, trademarks and legal matters, but there are also professional ethics. Ideas and concepts are getting recreated all the time, that's life. But it's also why people post sketches and ask if anyone has seen anything similar, only to discard them and move to another concept.

As I said in the (edit) of the original comment, the originality is secondary to the timing.

When you finalize a logo, you typically run a quick due diligence (a Google search) to see if you reinvented a wheel. If you did, you scrape it and start afresh. Tox didn't do that and they should've.

Oh, I see you helped yourselves to my Secure Chat logo -

http://dribbble.com/shots/479881-Secure-Chat

http://logopond.com/gallery/detail/165288

https://www.google.ca/search?q=secure+chat+logo - first page hit too

Not cool at all, "cool guys around the world".

--

(edit) Regardless of whether this was copied, over-inspired or independently conceived (but let's be realistic here), the generally accepted rule of the game is that the first to the finish line gets to keep the logo. I don't make my living with logo design, but I did kill a week of sketching, refining and re-balancing on this one and I do happen to like it a lot. For what it's worth, I wrote a P2P VPN system in the past (called Hamachi) and I am involved in p2p and crypto domains in general. So I expect you to extend some professional courtesy, change the logo and close this matter in an amicable matter.

This works and it works reasonably well.

I had used simultaneous-open TCP punching as a fallback for UDP punching when I was doing [0] and it did help in 10-20% of cases when (a fairly elaborate version of) UDP punching failed. That's on a scale of several hundred thousand mediated connections per day.

One caveat though is that it requires implementing a bot-like functionality in the clients, meaning that a mediating server should be able to tell a client - "create a socket, bind it to this ip:port, wait, wait... connect to that ip:port". Obviously, this is an ideal platform for DDoS attacks if someone ever manages to re-point clients to a rogue mediation server. So, yeah, it works well, but there are some not so obvious trade-offs.

[0] http://swapped.cc/hamachi

Here's an autopsy of my foray into this domain - http://swapped.cc/certtime

My takeaway is that this is a variation of an insurance business - you have to sell people on needing protection for times when sh#t hits the fan. It's an unpleasant topic and very few would ever want to concern themselves with it, at least voluntarily. So making something like VirtualNotary work is pretty much exclusively a sales and distribution problem. The technical side is easy.

Thinkpad W520 w/ RAID.

It must be a laptop. Can't really take a desktop on a vacation, can I now? :)

Alright. Color me convinced.

Though limiting it to the breach of other clauses doesn't make much sense under the same argument - those who are breaching hardly give a damn about the license.

This is it. This is not the only way, but this is what worked for me as well.

od2n, the main problem for you at the moment is that you don't know what you don't know. So you have to try and recreate things in order to understand what's involved, how it's done, what are the limitations, etc. Software design is in a very big part an acquirable skill, so the only way to master it is to exercise.

With all due respect for Tufte, his focus has always been on the presentation and visualization of the data. While this has an overlap with the design skills required for the end-to-end software design, the overlap is only partial and not even that big in many cases.

Also, the Dont Make Me Think book should've really been a two-pager pamphlet, it is really thin on a material. While the center idea is fundamental, it is very easy to explain and to understand.

If we are talking about 10000 ft perspective of the design and its fundamentals, I would raise you The Design of Everyday Things. This is a very good beginners book and it's also an interesting read for those who already know a thing or two.

http://www.amazon.com/Design-Everyday-Things-Donald-Norman/d...

A software being used to facilitate the spread of malware.

Or being used as a part of a scam operation.

Or being used by an entity that creates a negative impact on the company's brand.

Clause 1 is a standard DISCLAIMER in many O/S licenses. That's the source of it.

Clause 2 - Correct. This is a straight-forward translation of the legal speak. Again, fairly standard, you've just not been paying attention :)

Clause 4 - As I explained in another comment, this yet again appears to be a standard way to protect against unforeseen abuse. For example, someone's using the software to facilitate phishing ops or something to that end.

Clause 5 - The lease/rent/lend is a standard clause in many licenses, e.g. [1]. The "sell" clause also made an appearance in several I looked at, so it only seemed reasonable to combine these two.

[1] http://technet.microsoft.com/en-us/sysinternals/bb469936.asp...

Well, then you don't agree to it.

> I cannot modify the software? Why not?

To spare the company supporting randomly modified versions.

Also, the "cannot modify" clause is a weaker version of a universally used "You shall not decompile or reverse-engineerthe software", which is also frequently coupled with "You will not try and defeat, deactivate, bypass, remove or otherwise circumvent any software protection mechanisms". I don't think it makes much practical sense, but this is an industry standard. Virtually every proprietary software license is locked down this way.

But how come it makes sense for online services then?

I've seen this in more than one license to date, I'd say it's not that uncommon. From what I can tell, this is a way to deal with the unforseen abuse situations.

No, duh. Of course this is not the actual wording.

It is here instead - http://pastebin.com/C91fEqAf

Been there.

I had several EULAs drafted and/or proofread by lawyers. Inevitably, they feel that if they don't add a bucket of legalspeak, they weren't earning their money. When pressed if this or that wording really needs to be that contrived, they would come back with "not really, but better safe than sorry".

On the other hand there are much simpler licenses that are widely used and that are in fact human readable. BSD and MIT licenses being a couple of examples.

I have released several projects under conventional multi-page licenses, covering everything from not suing "licensees of data providers" and force majeure (that may or may not be different from the acts of God). This time around I have a simpler project and I want to try a simpler plain-spoken EULA that boils down to this:

  1. This is an "as is" software 

       that may break
       in which case you won't go after the developer

  2. You won't do objectionable things with the software 

Have anyone tried this?

There's just such a stark difference between, say, a BSD license and a license that comes with a typical Windows/Mac software. But since BSD clearly works, so why not try and keep things simple?

EDIT -> added "that boils down to this"

Amen.

I have the same setup as you - vanilla vim, barely customized and the development pace is hardly any slower than when I use Visual Studio with all its auto-completion, deep syntax parsing, etc. I saw Jonathan Blow (of Braid) saying that auto-completion and better debugging support is a deal-breaks for him, but everyone`s work pattern is different and I`ve seen plenty of cases where people using vim accomplished far more and faster than those with fancy editors. Tools are important, but they are secondary.