nupark2

> 1. Rich webmail is an absolute must for me. I use too many different computers from too many different places for anything else to be remotely practical at this point.

That's what IMAP is for. If these are computers you don't directly control, then I'd say any downsides of using gmail pale in comparison to the security implications inherent in your usage model.

[edit] Can't say I understand the negative downvotes. Maybe I inadvertently denigrated people's preference for webmail over mutt/mail.app/etc?

Regardless, the fact is that if you're utilizing webmail for remote e-mail access on shared computers, then there are much more significant risk scenarios at play than those of gmail.

The primary reason I won't outsource this service is trust. I don't trust anyone with that data.

Access to my email allows for resetting all my passwords, seeing all my contacts, and tracking literally everything about my day-to-day business and personal life.

SpamAssasin will auto-update its rules if properly configured. I have touched my SA install in years.

I'm not sure where you're spending time on maintenance. I set up my current mail server 3.5 years ago (postfix, spamassassin, dovecot, sieve, roundcube) and barely ever touch it -- the only maintenance required is the very rare security update.

I use tarsnap for backups, so no tapes required.

I don't love running my own mail server, but as a hacker, I don't see that any of the alternatives are better.

Actually, I believe many vacation home rentals were (and are?) done via VRBO.

Renting out an individual apartment -- even 'professionally' -- is not necessarily unusual, but increasingly difficult due to the spotlight AirBNB has brought to the process.

An AirBNB unit was rented out in our building, and was a semi-regular source of noise and trouble. So, we took the listing to the landlord and they shut it down: it's illegal here now, and it's specifically forbidden in the lease.

The more popular AirBNB gets, the more likely it seems that this sort of reaction will become the defacto one in popular areas.

This is already the case with large developments like Stuytown in NYC: http://www.betabeat.com/2011/05/31/airbnb-takes-manhattan-wi...

I think it's an accurate assessment. I live in NYC, and most neighborhood bars are not crowded and noisy as hell.

However, if I go to a "destination" for out-of-towners[1], then yes: it's packed, noisy, and insufferable.

Same thing with traffic -- most of the personal automobile traffic in the cities comes from commuters that don't live here.

[1] I was trying really hard not to say "bridge and tunnel" ...

> DRM period isn't a waste of money. DRM as it's commonly practiced is.

Not necessarily disagreeing, but DRM would always be a waste of money if it wasn't for the anti-circumvention laws that prevent disseminating DRM work-arounds.

The law serves to raise the bar on just how annoying DRM has to be before most people are willing to work around it.

This is the thing I hate about github.

Hacked up code is all fine and good, but what I'm looking for are the tools that are necessary to make it easy to consume the code:

* Stable, versioned releases, with sufficient API (if not ABI) compatibility across releases.

* Accurate and complete API documentation (with bonus points for higher-level integration documentation.

* A bug tracking system

* Mailing lists.

These are all historically accepted best-practices that have (and continue) to serve the OSS community well, but they're also practices that are strongly and innately de-emphasized by github's "code first" UX.

If github (and git) were facilitating the production of marvelous new libraries and software that we'd never seen before, then maybe I'd acquiesce that it's worthwhile to abandon the best practices above.

That, however, has not been my experience. Most of the code is poorly maintained, often abandon-ware, and with unclear lineage. It's unknown which of the 50 forks is the best one to use at any given time, and what the ongoing costs will be to track unstable development branches directly, since there are no releases.

What is a speed reading program? Are you referring to the types of software listed here:

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

> It seems strange to think that to represent everybody's need the web needs to be developed by everybody.

It's not that strange. It's hard to represent the needs of people that you don't fully understand.

When it comes to an under-represented cultural/social/racial group, I simply don't understand the market, what they want, or what is important to them. I don't come up anything like the ideas that entrepreneurial members of that group will come up with, and even once I've heard the ideas, it often takes a radical shift in my thinking to see the advantages.

Women make up roughly 50% of the population, but many industries repeatedly fail to provide the products that women would prefer -- as you've almost accidentally elucidated above with your comment regarding video games.

> It's wild to me that people are giving you trouble for "can't" when "ponderousnessly" is clearly the more compelling target. (An odd choice even if rendered as "ponderously". "Clumsily unlikely?" Eh, okay, I guess you can have it.)

I completely missed that one (and it's much more deserving than "can't"). I assume the size of the word caused most reader's eyes to flow right through it.

You win, regardless; ponderously was the intended word, aiming to convey the implication you've described.

That said, I wish the focus was on N-Control as an organization and the seemingly bizarre shadowy world of business they may inhabit, rather than my small missteps.

[Fixed above]

While I understand that I risked the ire of grammar (and spelling) nazis by invoking an argument for professionalism in communication, let's be honest: a small typo is a far cry from a seemingly near complete inability to articulate a coherent thought.

To put it more plainly: picking apart a small typo here is gratuitous.

It seems ponderousnessly unlikely that the principals of N-Control were not already aware of Paul Christoforo's loose grasp of ethics[1], customer service[2][3], and professionalism[4].

I'm not particularly convinced that the principals at N-Control aren't all that dissimilar to Paul Christoforo, or that he's not still somehow involved.

[1] His entire website is plagiarized: https://docs.google.com/spreadsheet/lv?key=0AnMPztotGCGadE1s...

[2] A previous example from 6 months ago: http://www.natesnetwork.com/Poor-customer-service

[3] They were dropped by a previous marketing firm when they brought Christoforo onboard: http://kotaku.com/5871400/cut-paul-oceanmarketting-christofo...

[4] The man can't even spell, much less formulate a vaguely grammatically correct sentence.

Unfortunately, clang (and the shared llvm backend) are still fairly buggy. For example: http://blog.clickablebliss.com/2011/11/07/xcode-4-2-llvm-bui...

There's a bug in Xcode 4.2 (the latest stable release) that results in broken armv6 thumb FPU-related codegen. It's not hard to hit, either.

Since everything is based on LLVM now (including gcc-llvm), there's no way around this one (or other bugs) other than simply disabling thumb.

I'd personally rather stick to gcc4 for at least the next few clang/llvm release cycles, since the bugs are known. Unfortunately, straight GCC is no longer supported in Xcode.

In terms of historical interest, it's also worth noting why McVoy restricted and eventually withdrew the BitKeeper license: Andrew Tridgell (of Samba and rsync) had begun reverse-engineering the protocol with the eventual intent of implementing a free client.

The resulting debacle was fairly ridiculous; Linux chastising Andrew Tridgell, continued flamewars about using a closed-source product.

What I find interesting here, though, is just how much hot water McVoy landed in. He gave away free licenses to Linux developers, then when someone in that community started reverse engineering his product with the intent to replace it, he revoked the free license, leading Linus to develop a replacement anyway -- one that has largely consumed the vast majority of BitKeeper's target market.

I believe these guys have an NDK-based implementation: http://www.apportable.com/

Which comes full circle to my original point, which is that other than Google, nobody with a vested interest is trying, and worse yet, they actively oppose progress on this front.

A VM that provides a standardized bytecode and execution model capable of executing most modern dynamic and static turing complete languages with sufficient performance. This requires more general facilities for common functionality required; refer to tail call support, JVM's invokedynamic, etc.

Or, shorthand, a general purpose browser VM.

Unless, of course, you're arguing that the above is not truly possible, in which case I'd argue that's exactly what Google is exploring via PNaCL, and has (if not completely efficiently) been implemented across existing VMs. The PNaCL choice of LLVM bitcode was likely in error, but regardless, "no such thing" is a stretch.

At the surface level, I could see how your position would appear logical.

However, the nature of the replacement VM doesn't really matter in the context of what we're describing here.

The problems of compatibility remain the same regardless of whether the target VM is a JS-specific VM, or a general purpose VM; reliance on undefined behavior, accidental changes in semantics, optimization bugs, and so on.

If browser makers were able to swap-out the VM, they've already demonstrated the ability to solve the exact same kind of compatibility problems they'd face here.

We were actually discussing JS VM replacement in the browser, related to:

> True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways.

The counter-point being that all the major browser vendors have swapped out their VM or performed significant rewrites in the past few years; it's clear that it's possible to implement a new VM and not "break the web in profound ways".

> Enumerate all the features of the web you can think of that have enabled it to explode and thrive compared to networked applications and the popular VMs of the last 20 years.

Ubiquitous cross-platform adoption. Done.

The web grew popular (relative to the Internet population) before it got JavaScript, not after. It wasn't JavaScript that drove widespread adoption, and it wasn't applications built in JavaScript.

First of all, it's difficult to engage with your productively, as you're particularly confrontational.

That said, if you give me some example code, I'll demonstrate its use in a JavaScript/Java hybrid implementation when I have some spare moments.

I think your points are valid as well.

I'm not ready to take it as a given that we can't build a general purpose VM capable of running JS at or very near current speeds, but it's also not a solved problem.

> JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages.

I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.

The investments here occurred long after the VMs were developed.

> The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly.

The same applies to compilers across the board; we do not know how to make a compiler that applies all possible optimization available to code always, either. I still have to manually vectorize critical paths, re-order code (sometimes in C!) to help the compiler avoid pipeline stalls, etc.

Instead, we do the best general purpose job we can, and it's usually more than fast enough.

What we're talking about here is a VM that has JS support as its first-order target. Using the JVM and CLR as performance examples here -- given what they were built for, and when -- is not particularly valid.

Speaking to NaN-boxing in particular; it's one solution to the problem, but not the only one. I'm going to remain unconvinced here, given that dynamic languages have almost always been a late, second-tier concern for anyone investing serious R&D in the development of a VM/JIT/compiler.

All that said ...

> The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.

Even given the above, implementing a custom optimized JavaScript VM -- even if it was only available in JS-only case -- would not be a failure scenario.

Both directions. There are impedance mismatches, of course, but it's nothing like the doomsday scenario he's claiming.

> Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language?

Your argument was that it wasn't technically achievable because it would break the web, yet it's clear that it can be done and HAS been done.

I'll try to address this new argument.

JS isn't perfect, it will never be perfect, and the lack of a bytecode VM is a hindrance to experiments and production language implementations that can lead to better solutions for developers.

Look at the language design that has occurred elsewhere. I may not use Erlang, but I learned a lot from it. Clojure introduced a ton of interesting concurrency constructs (among other advances). C# demonstrated LINQ, and F# is OCaml revisited.

In all of these cases it has nothing to do with whiny developers "refusing to write in anything but their favorite language". We're simply attempting to advance the state of the art, because nothing is perfect, especially JavaScript.

> This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging:

It's a work-around, not a solution. JavaScript still isn't an efficient bytecode format, this won't solve performance issues. We've seen similar work on languages that compile down to C, and it's not an adequate solution to debugging, especially when the debuggers benefit from language-specific enhancements.

Your concerns seem ill-founded given that these are solved problems. There are working implementations of low-barrier cross-language compatibility, today, for both the JVM and the CLR.

Here's one example; Rhino provides pretty seamless bridging from JavaScript to Java:

https://developer.mozilla.org/en/Scripting_Java

I've used it to run user-supplied JS inside the JVM.

PHP is pretty easy too:

http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp#JavaPH...

Scala is even more lightweight here:

http://www.codecommit.com/blog/java/interop-between-java-and...

Bear in mind that these are all for the JVM, which wasn't even designed with the intention of being a general-purpose multi-language VM.

> why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes?

You have to remember that HTML is predated by SGML, and that HTML and its precursors were designed for the purpose of providing document markup. We've continued to evolve these solutions for document markup, and in this regard, they do an adequate job.

However, what we've seen in recent years is a rapid emergence of the use of HTML and JS for producing fully interactive, stateful, and performance-demanding applications. This wasn't due to the suitability of HTML for the task, but rather, due to the lack of any other reasonable standardized competing platform.

HTML has fallen over in this context; the DOM is ill-suited towards standard re-usable UI widget programming, JS is frustrating for building large applications, the performance profile is tremendously bad on mobile devices. This has led companies like Google to task teams with exploring how to fix HTML to be more amenable to application development -- whether it be dart, replacing the DOM, NaCL, or otherwise.*

> Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed.

Highly flawed. Java's plugin implementation was incredibly technically flawed (just look at the startup times), as was Adobe's (for different reasons). Moreover, Adobe Flash was not standardized, the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product.

However, this does not mean a VM isn't possible; that's what we already have today, with V8 et al.

> Or "better" yet, some real universal client that works like Display Postscript or X-Windows?

Would that be better? There are plenty of fundamental technical reasons those approaches for networked applications did not take off.

Of course, one could argue that <canvas>+webgl provide a modern successor. A generic rendering environment with client-side code execution.

The JVM and the CLR have already adequately demonstrated that multiple languages can easily (and with adequate performance) share common libraries and APIs.

Mixing Scala, Java, Ruby, JS, and PHP -- all in one process -- is simple and straight-forward on the JVM.

That said, the language of the web is HTTP and REST and open APIs, not injection/eval of JavaScript.