pifflesnort

Trying to turn native apps into template-styled web apps is just backwards; you're discarding the fine attention to detail, typography, pixel-positioning, scaling animations, etc, that can make native apps so great.

It still is a broken design that you can ever lose history or hose a repository in a tool that is designed to store history, forever.

That's a sharp edge that should be exposed, and its not the only one in git.

Given that EA's Monopoly for the iPad has a built-in Prius to serve as one of the game pieces, I'd say not trusting them is wise.

> You can not set a homescreen secretly or in the background, and you can only have a single home screen set at any given time.

A great many toolbars aren't "secret", they just engage in indirection to trick users into agreeing to installing them.

> If the user decides to install a homescreen, and he does not like it, He will simply uninstall the app.

Assuming the user even remotely understands what happened.

I'd call the inability for Facebook to usurp control over Apple's vertically integrated platform to be a market advantage, not a liability, as long as too many users don't start clamoring for a facebook-iphone.

[edit] Remember browser toolbars? Now that Facebook is doing this, I expect this is just the beginning.

I can share an anecdote from the reverse perspective. When traveling in Morocco, I didn't speak any local languages (eg, French or Arabic). I also was entirely unfamiliar with the city, the distances between points, or even how much something should cost. If there was a Yandex app, I wouldn't have known about it (... although the last time I was in Morocco predated smart phones by about 10 years).

This meant that negotiating a price was pretty much out -- I paid what they asked, and had no real way to gauge whether that was reasonable other than asking a local. I also had no recourse if they overcharged -- what was I going to do?

Information asymmetry is a potent weapon for taking advantage of people, whether it involves taxi rates, or just how clean the restaurant's kitchen is, or how fresh the ingredients are. This is why we have regulations that attempt to provide some of the symmetry required for fair exchange.

Unregulated innovation often innovates fraud and crime when you're talking about unmarked, unregulated cars driven by unknown people, picking people up off the street.

If you go anywhere in the world with less strict taxi regulation, you'll run into this. In Prague, my wife and I hopped into a cab only to find that the meter seemed to exist in a time bubble that ran 10x faster than the rest of the known universe.

I appreciate being able to hail a random car on the street and know exactly what I'm going to get. Safety and fraud issues are exactly why the industry was regulated in the first place.

> If the restaurant provides free bread (and a large portion of them do), I think it's entirely permissible to combine them.

They provide bread under what most people understand to be the social contract: that you will order more than a side of bacon.

Some restaurants -- especially those that serve students -- even require a per-person minimum order to ensure that they're not losing money on cheapskates.

You, sir, are a cheapskate, in that you're willing to break the social contract as to further your own interests, while transferring the cost of your benefit to your host.

> Your suggestion that my disclaimer only exists in an "upside down" universe suggests you don't agree with that assertion.

No -- I don't agree with a social movement that induces you to lead with an apology for an innate traits such as your gender.

The disclaimer made me cringe: "as a man writing about gender inequality, I acknowledge my privileged (and biased) viewpoint in this discussion."

In what upside-down universe is it considered necessary to pre-emptive apologize for what you are (a man) and what you might unintentionally do (offend someone's sensibilities)?

These kind ridiculous expectations of others is why the Adria Richards thing blew up, not because of (quoting the article the author links to) "One Brogrammer's Sexist Joke".

> Interning at the same place twice yields diminishing returns: you'll be working with the same tech, not meeting new people and learning new tricks. Plus, you won't get to experience more company cultures, finding out where you fit.

Unless you want to work there after school, in which case returning is a very good idea, because the whole point of the returning internship pool is recruitment.

> Don't even consider interning part time during the school year. The pay will seem appealing, but it will take away from your college experience. You only go to college once, you should enjoy it to its fullest, you have your whole life to work. Again, money is insignificant compared to your life earnings.

There are lots of reasons other than money to intern part-time during the school year. It provides an outlet to do real-world work and build relationships that will matter for years to come after you've graduated.

The interns who continued to work in some part-time capacity when I was at Apple (and who continued to make solid technical contributions) were almost invariable hired.

> Interning in the Valley is a rite of passage, but after you've done one internship there, consider other places. NYC is great, I live there and highly recommend it

The company in question and the work you're doing matters as much or more than the location you're in. Obviously, you want to live somewhere nice, but if you want to work at a specific company, then that should be what drives your internship decisions.

On the subject of the bubble and April Fools, I have a great example of the Internet enabling great April Fools pranks.

At a .bomb startup in the late 90s, our own company ran a stock ticker website. On April fools, someone got together with IT and MITM'd the stock site, showing our share price plummeting.

This could have been particularly evil, but the joke was disclosed early on.

That's a prank, rather than this marketing drivel where companies announce clearly ridiculous features and products.

> Now that I think about it, a physical exhibit where they can recreate the hardware (even if only on a superficial level of aesthetics), and the rooms and settings where that hardware would have existed, and the software it ran would be incredibly interesting. It would essentially be as close as we could get to a time machine for the foreseeable future. That kind of exhibit would probably become one of my favourites very quickly.

I agree, that would be fantastic. You see hardware (especially Apple's) show up in fairly prestigious design museums (eg, http://www.moma.org/collection/browse_results.php?object_id=... ), but it's never functioning, much less available to actually use.

> The problem i've had sometimes though is that whenever I try using some old software (which is mostly games as I was born in the 92), I often get stuck in making the game play nice with the current set up, regardless if I run it in compatibility mode or not. I guess I should set up some VMs with older OSes, just for this purpose.

Emulators are also valuable here; the work done on bsnes is amazing, and MAME does a pretty solid job of emulating hardware (including old Mac hardware) accurately.

There's also still quite a lot of retro hardware and books for sale through used markets; enough that people make it their (if not particularly lucrative) business to collect and resell 'vintage' hardware.

History tends to filter out the bad ideas, such that many of the best ideas survive today. However, human's cultural filters are not perfect, and there are lots of good ideas and intellectual context that can be exceedingly valuable to understanding how things became the way they are, or demonstrating alternative paths (which may even be better than what we have today) that did not emerge for market, financial, or cultural reasons.

I really find historical technology to be edifying in the same way political, musical, and broader cultural history is edifying. I think it's a shame that we don't spend as much time teaching technology/design history to software engineers as we spend training 6th graders to understand their local political/cultural history.

Here here!

I make an effort to buy old software on eBay when I come across it, archive it in a stable format scan the media, and then store the originals.

It would be nice to see a project (would archive.org host it?) that applied standard archival rigor (http://en.wikipedia.org/wiki/Archivist) to preserving our computing history.

I'll leave freebsd-update aside, since Colin already touched on that.

I too am old, and often extremely grumpy. That said, I think you might be having a "senior moment" regarding your recollection of administering SunOS systems, if you're comparing the hassle of SunOS to FreeBSD.

It looks like your network is failing.

Wow. That's a totally awesome feature I was not aware of. There are tons of use-cases for being able to do things like run a real TCP/IP stack in userspace.

Tools such a http://en.wikipedia.org/wiki/Slirp had to hack the BSD networking stack considerably to run as a userspace process, and is used to power networking in emulators, mobile phone tethering, etc.

I'd start with:

board [at] freebsdfoundation.org

and/or

cperciva [at] FreeBSD.org

There's honestly no harm in discussing it. FreeBSD/Xen is already of interest to base committers, there's existing work done.

If those committers are interested in furthering it via funding -- something you can only establish by talking to the foundation et al -- then everyone wins! :)

Agreed. Talking to cpercival would also be a good start. See his page on the subject: http://www.daemonology.net/freebsd-on-ec2/

Also: https://wiki.freebsd.org/FreeBSD/Xen

I think that funding whatever is required here would be fantastic. The move to VPSs has forced me to also move to Ubuntu for what I host 'in the cloud', and I'd love to move back to FreeBSD.

Perhaps you could constructively expand on this?

For the most part, I find managing FreeBSD to be painless, with one glaring exception I'll get to in a minute. I really love that the base system and the 3rd party packages are iterated separately -- I can have a stable base OS, while also running modern software.

The problem is the ports system. Building your own software is a nice option to have, but it's usually just a waste of everyone's time, and it tends to fail in annoying, new, and magical ways.

Fortunately, we have https://wiki.freebsd.org/pkgng coming down the pipeline, which solves the problem (finally).

On top of the hassle of using ports, writing ports is a huge hassle of battling archaic crap. Rather than using destroot, like every other package manager from the past 15 years, FreeBSD requires the package maintainer to manually list out each file that will be installed on the target system, and will fail to properly clean up ports if those file lists are incorrect.

That said, it's not all that much worse than what's necessary to produce a debian/ubuntu package -- it just could be better.

That's a bit ridiculously alarmist, isn't it? Heck, you could have lead with that, rather than waiting for me to reply -- you seem to already know what you wanted to say.

Won't developers have access to PNaCL runtimes? How is this so different than Apple developers having access to the other target hardware

It comes down to toolchains and the workflow they're optimized for. With PNaCL, the portable version is the primary target of the toolchain, from which one generates other native binaries. You can still generate native binaries separately, but ideally, PNaCL would lead.

If the tools lead naturally in the right direction, then developers do follow. If you're feeling really worried about it, define a distribution format that mandates a PNaCL entry.

How did Apple developers ship working PPC/m68k binaries? Or PPC/x86 after that, later PPC/x86/x86-64, and armv6/armv7/armv7s on the iPhone?

> By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems.

That's not really how NaCL works. Any instruction that can't break out of the jail can be whitelisted; this includes all versions of SSE.

Additionally, PNaCL can be retargeted at as-of-yet unknown architectures.

The result is that binaries would have been either shipped as PNaCL-only, or optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped, new binaries could be targeted appropriately.

This seems reasonable to me; default to portability, provide an option for best-case performance.

rorr, you appear to be hellbanned. Here's your comment, since it seemed like a reasonable one:

> Now, imagine I created a third benchmark that did something more complex, like executing a database query and serving the results using the html/template package. There would be a negligible difference in performance across frameworks because routing is not going to be your bottleneck. If you're performing a DB query on every request, you're doing something wrong. In the real world your app will check Memcached, and if there's a cached response, it will return it. Thus making the framework performance quite important.

> I think the inverse is what we're talking about. Will we be able to browse NaCl sites in future browsers (possibly after an architecture change away from x86)? As it stands, we would probably be able to browse a 90's site on modern browsers.

Given PNaCL, the answer should be 'yes'.

> Show me a counterexample, that's all I ask. I'd give all the rhetoric in the world for a single damned counterexample of a program format that's lasted since the 80s. That's what's at stake.

ELF was defined in the late 80s/early 90s as part of SVR4. COFF was defined as part of SVR3. Both still exist today.

The JVM bytecode was defined in 1995 and has been evolved compatibly.

I'm curious, though. Do you require the same longevity of web formats that were defined in the 90s? Things have changed quite a bit, and attempting to browse the modern web with a 90s browser is futile.

Given that, I don't really understand what you're arguing for.

> Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry.

Us 'bearded old men' aren't on the web, and its only improvements like SPDY, WebSockets, and NaCL that have made me the slightest bit interested in the web as an application platform.

NaCL is gated on PNaCL. NaCL can provide optimal performance, PNaCL can provide portability.

> ... there's sufficiently plausible technical and political resistance that we're probably never going to.

Resistance that you contribute to with almost every article that touches on NaCL, yes.

It's self-fulfilling prophesy and a circular argument: "We can't adopt NaCL because nobody will ever adopt NaCL" -- say the people responsible for choosing whether to adopt NaCL.

> So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS.

Why is this the "inevitable" result?