pbsdp

brew just seems like a less mature macports. most of the differentiating features have disappeared as brew gradually discovered the same problems that macports/fink had already learned over the past decade.

The problem is that you have a complex and exclusionary process to begin with.

The comparison with open-source isn't apt; inclusion in the mainline of an open-source project affects every user of that project. Keeping code that does not fit with the goals of the project negatively impacts existing users of that project.

Not so for SO questions, or for Wikipedia pages; a page or question you never see, but contains useful information you don't personally think is notable (or "constructive"), costs you nothing to keep.

This is just the Wikipedia editorial/deletionist problem. Some people are more interested in enacting and enforcing process and community "norms".

Expert opinion is useful; aka, constructive.

Thus creating a closed loop ecosystem that grows increasingly stale.

I don't really understand what is low about it. Systemd didn't just appear one day; Poettering has written and advocated for it strongly.

Really? I admittedly mostly used MAE on Solaris -- which emulated a 68k processor -- and it was reasonably fast.

I never had cause to use SoftPC.

Really? Google has the knowledge of where the network is, who has access to it, and what the password is. Remember also that WiFi networks are a shared resource and often provide access to internal corporate data.

From a governmental law enforcement perspective, that's an incredibly valuable trove of data. Instant network backdoors, likely with no physical entry required.

Even if you're not using the data to sniff networks, you can use it to build detailed relationship graphs between people and places.

MacTCP was acceptable, but certainly didnt stack up against the UNIX variants.

As a Mac user at the time, the love for Windows 3.11 left me scratching my head something fierce. By comparison to System 7.1+, Windows 3.11 was awwwwful.

Of course, around that time you could also run an Irix desktop, complete with Photoshop and SoftPC and even (later on) IE, but that was sadly beyond the reach of most consumers.

> asm.js is JavaScript. It executes according to the semantics specified in ECMA-262.

No, it's a strictly defined text-encoded bytecode that happens to be representable using a subset of valid JavaScript. If you deviate from the standard using valid JavaScript, you lose the gains.

Calling it "JavaScript" is just a semantic game. You can't output arbitrary but fully 100% standards-compliant JavaScript from a compiler and expect asm.js to do anything meaningful.

> Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.

The irony is that these things fail because of the people who wish to maintain the status quo, and then those same people point to the failure as justification for maintaining the status quo.

It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from you.

I'm not attacking your choice, I'm just saying that according to my ethos, taking BSD licensed code and relicensing under the GPL is:

1) Rude.

2) Simply the cost of doing business under the BSD license.

Can you expand on why? OpenVPN has long been an example of solid development (and crypto) practices.

As far as the bastion host, you need an actual VPN to do more than forward SSH connections. For instance, connectivity to your LDAP server, internal web services, etc.

Port forwarding gets you part of the way there, but it's inconvenient to use with SSL, requires using weird local port numbers when connecting to services, etc.

SSH does have VPN support via tun/tap, but it's not nearly as functionally complete as OpenVPN, and you still have the entire SSH authentication path exposed to the world.

> By saying this, you are saying to me that I am free to re-release your code under the GPL and add my own contributions. If you are not happy with this arrangement, you have made an error in your license choice.

No, I'll remain content with my license agreement, I'll just think that you're a dick.

That's OK, though -- some people behaving like dicks is simply the cost of collaborating openly.

You're engaging in standard GPL goal-post moving; somehow if you redefine all the words we'll all accept that the GPL isn't a restrictive viral license.

> JS is a relatively fine compile target ...

No, it's not.

> ... and with asm.js, a pretty fast one.

And asm.js demonstrates why it's not, because asm.js isn't JavaScript. It's a strictly defined ASCII-encoded bytecode that happens to be representable using a subset of valid JavaScript.

At which point, one must ask, what bizzaro-world engineering justification do we have for using a JavaScript subset as a first-order bytecode format? Why couldn't the silly JS bytecode format be a second-tier target for legacy browsers that don't support a proper format?

On top of which, why are we willing to throw away 2x+ performance (in the best case)? Is the iOS/Mac App Store not successful enough for us, such that we absolutely refuse to try something other than adding more JavaScript to every problem we face with web app deployment?

To be granted an enterprise or standard developer signing certificate, you must agree to a contract that stipulates the valid uses of that certificate.

I think it's reasonable to call blatant disregard for contractual obligations "illegitimate".

> By that reasoning, all software licenses are viral. Even the 2-clause BSD license would be viral, because you're not permitted to distribute it combined with code that it's incompatible with.

You're reinventing definitions to suit your argument. The BSD license creates no restrictions on what you can combine it with. The restrictions are defined by to the GPL.

> I wouldn't be happy with that arrangement if it were my code, so I choose a different license.

If you're approaching this from an "ethics of sharing" stance, then what what you're actually restricting is somebody else's use of their own code. Your code never disappears/changes/gets relicensed, it's their code that you're staking a claim to.

Now, if you're approaching this from a stance of withholding certain valuable rights to your code, such as the ability to be the only person that licenses closed source usage, then the argument is a bit more logical.

> They are free to open up their code to me if they want to use mine.

I do. Under the MIT license.

The difference is that exposing OpenVPN code allows you to separate remote access from your production services, both reducing the total attack surface and providing defense-in-depth.

On top of which, OpenVPN has actually had fewer security vulnerabilities released than OpenSSH, and HMAC validation enormously restricts the surface area of exposed code as compared to OpenSSH.

OpenVPN:

- Exposes less code to attack

- Can be run on a single machine, distinct from your production systems, where compromise will only result in a compromise of VPN communications, not of an actual production machine on which your production data/processes exist.

You're assuming writable trampolines. objc_msgSend()'s trampoline works by caching the target lookup and having an extremely short fast-path in the case that the target method implementation is cached.

objc_msgSend is a trampoline in the sense that it leaves the frame/registers untouched and jumps straight to the target implementation.

That said, you can implement the kinds of trampolines you're referring to without writable code pages, it just requires more work: http://landonf.bikemonkey.org/2011/04/index.html

What sane person exposes SSH externally?

- OpenVPN takes only minutes to set up

- There are easy to use GUI clients for all major desktops (Windows, Mac OS X, Linux) and phones (Android, iOS)

- It supports running with zero privileges (chroot+setuid) since it only needs to forward packets to /dev/(tun|tap), which does not require privileges after the device has been opened.

- It limits your compromise exposure to only one edge gateway (you can put any number of machines behind a single dedicated gateway). If the gateway is pwned, you still have the defense-in-depth of internal SSH, internal encrypted comms, etc.

- Supports HMAC validation of incoming data to avoid any complex processing (and thus exposure of bugs) of packets from users that don't have the shared HMAC key. This means that only the HMAC code is exposed to untrusted users.

- Supports public key +/ password authentication.

There's no reason to expose SSH to the public internet when you can run a gateway that handles only VPN traffic and greatly limits your attack surface. Defense in depth!

Sure there is. Remember how your iPhone had to be activated with the carrier?

Or how all that analytics software would use the MAC either as a UDID, or to derive one?

The ageism in your post is disconcerting. On one hand you equate youth with innovation, age with stagnation, and on the other you posit that overworking youth for below market wages is simply a cost of doing business.

HTTP improvements are necessary. If this raises the bar past what some developers can manage, that's unfortunate, but necessary -- the current system actually prevents what better developers want and need to do.

Engineering is about making complex things simple and easy for your users. Sometimes that means increasing complexity at one level of the stack to increase performance and functionality at a higher level of the stack.

So how do you debug the myriad of binary protocols that already exist today? How do you debug SSL services?

For that matter, how do you perform more than cursory debugging of HTTP services? Do you seriously sit there and carefully type out HTTP 1.1 compliant requests, along with requisite headers and maybe even cookies? Does that actually work for debugging complex issues, and does it really differ that substantially from the debugging one performs to see if a binary protocol service is up and accepting requests?

This is just scaremongering. Installing the command line LDAP tools (which is a horrendous binary protocol) is no harder than installing netcat or tcpdunp.

Since binary protocols are easier to write tools for -- and difficult to us without them -- the tools get written.

Slowing down everyone forever just to ease telnet debugging is a misdirected optimization.

When its easier to write tools, tools are more plentiful. Same binary protocols make it an afternoon's work to implement most protocols, and even less time if all you want to do is open up a socket and send some EHLOs.

Text protocols, on the other hand, require writing a parser, dealing with encoding back and forth between string representations and binary data, handling line delimiters, etc.

I'll take binary protocols any day of the week. Any cost they incur in not being human readable is offset by the value of them being so easy to implement.