Apps do work better with GMail. Their calendar and mail, in particular, are somewhat more tightly integrated than you might want -- and invitations to a calendar event pretty much only work with a Google account, even if the recipient doesn't use Google Calendar.
I'm sure I could find other things if I tried. Some of these would be hard to do in a more open fashion. All of them do, in subtle ways, suggest that you use more Google services.
And there are the privacy issues, but that's separate from the monopoly issues.
I agree, though, Google is not a huge problem. For all the control they appear to have, there's still quite a lot of opportunity to just not use them. Even if you absolutely need that YouTube video, you can always kill tracking cookies.
Microsoft, on the other hand, is nearly impossible to avoid.
they'd gain back some of the epic amounts of geek credibility they lost during the OOXML debacle
Some. The OOXML debacle is only the latest in a very long line of typically Microsoft practices.
Their geek cred has fallen a long way. Just as they would have to do everything wrong for over a decade before money was an issue, they'd have to do everything right for over a decade to earn back the respect they've lost for pretty much their entire existence.
Really, what do you think a judge can do about it anyway?
Acknowledge it, maybe? Instead of brushing it aside and attacking their competitor, showing clear favoritism?
What's done is done.
In the case of bundling IE vs Netscape, yes. Does that mean they can't still be prosecuted for their many (broken MS Java), many (per-unit licensing vs per-Windows-unit for OEMs), many (OpenXML and ISO) predatory business practices?
And yet, this is the woman who says Microsoft is "so last century". It's difficult to think of a market harder to enter than the desktop OS market, or the office productivity suite market.
For me, Microsoft is so last century. They are not the problem.
I don't know about you, but my father uses Windows. My mother uses Windows, except for an old machine I've set up for her music library on Linux. My brother uses Windows. His friends all use Windows. Most of my friends use Windows, except the few who have Macs -- and those run Windows in a VM.
Even I use Windows -- VM or dual boot.
I've finally reached a point in my life where I don't have to touch Windows more than once a week, unless I want to play a game. And yet, I still can't design web apps the way I want -- I still have to either force everyone to download Firefox, or spend around 10% extra development time supporting Internet Explorer. (And I can't develop IE-only, or I don't have Firebug.)
If you don't see Microsoft as a problem, you aren't looking. If you see them as "so last century", it's because you let them get away with it last century!
I'm not going to defend Google, but that statement is dangerous thinking. Just because everyone forgot about the problem doesn't mean it's gone.
Isn't building that one golden application that pays for your datacenter so you can unleash your other mad-scientist type plans on the world the holy grail, so to speak?
Except that while building that application, you really don't want to be hosting it out of your garage.
So yes, it would start on my own hardware -- as in, my laptop. Then, if I wanted it to be remotely serious, I'd put it up on Slicehost and let them take backups. If I started getting some serious traffic, I'd branch out to Amazon EC2 and S3.
Then, once I've actually built the next eBay or whatever, it might be worth considering building my own datacenter. But it's just not cost-effective for a small app -- I don't even need an entire machine, and I certainly don't want to be buying several machines (and several network connections, for redundancy), UPS, cooling, etc, when I'm still effectively a Mom&Pop operation.
I mean, I get it -- it would be cool to have all that stuff. But it would be a lot of work to maintain, and it'd be a waste of money, considering the alternatives.
Last I checked, IE8 was still far behind everyone else in standards compliance, and that's with the same standards (XHTML, CSS, JavaScript) that have been with us for a decade. That says nothing of the brand-new standards people are inventing (HTML5, SVG/canvas) which IE hasn't even touched.
I place the blame squarely on IE for the amount of Flash we have now.
And yet, they're breaking enough compatibility that Google.com (and Microsoft.com) won't render properly. Which means they've chosen to make IE8 another IE7 -- break tons of compatibility, probably introduce tons of new UI for no good reason, yet still be the least compliant browser in existence.
The smartest thing for them to do would be to break compatibility entirely, and start with something that's gotten it right -- Webkit or Gecko.
and Direct3D for what's still left of Microsoft Windows and believe me when I say Linux and Apple are going to kill Windows
That makes the rest of your post hard to take seriously. Five years? Really?
You know, as bad as Vista was, people bought it. As bad as Direct3D was when it started out, it's actually to the point where many people seem to prefer it to OpenGL.
The whole machine can use a maximum of 90 watts, and tends to run just fine with a 60 watt adapter.
That's maximum. Typically, it's more like 20 watts -- again, for the whole machine, including a monitor.
Right now, for HD video, it might matter. In 5 years, it won't. Put another way, I used to actually care, and research, how much CPU a given piece of hardware might need -- or how much might be offloaded to, say, a network card. Used to be, hardware RAID had a point, too.
Now, it really doesn't matter -- CPUs are fast enough that it's cheaper to buy (and operate) a 10% faster CPU than it is to buy a RAID card.
I'm guessing the same will happen for HD video. As for games, we already know how that goes -- at a certain point, raytracing scales better than rasterization.
Worse than that, it seems to be about the vulnerabilities of not using SSL, not anything inherent in SSL itself.
Unless I'm mistaken, the only vulnerability in redirecting all HTTP traffic to HTTPS is that users might type paypal.com, end up on https://paypals.com/ and not notice.
Sensationalist, as usual.
Granted, most sites are still quite a bit worse off than that -- forms served over HTTP that send your password over HTTPS -- but as usual, there are simple workarounds. For example, bookmark https://mail.google.com/ -- problem solved for Gmail.
more power - no, the server controls your data and you have to be the kind of person who knows what a web scraper is and how to write one to get it out without spending $BIGNUM hours.
I think this is probably talking about things like the universal access. After all, the amount of additional power you'd have out of having the data locally is again relative to if you're the kind of person who knows how to write data mining software.
reliability - depends on whether you're better at managing your local app than the bottleneck of you managing to always have a connection and them managing the app.
Almost no one is good at managing a local app. Ask ten people if they do backups -- I bet nine of them will say "no".
And you don't really have to. Your connection dies, you pick up a laptop and go to a coffee shop. Problem solved -- or at least, now it's your ISP's problem.
centralized support - whether that's good depends on how good support you can get. Your mom is going to prefer good support from you rather than mediocre support from "Robert" who works in Calcutta.
And I'd prefer she talks to Robert, whose job it is to help her. Either way, chances are she'll have fewer problems to begin with.
if you delete a mail from your yahoo mail account, can you get it back?
Probably not. That's why it's not generally easy to delete things -- Gmail, at least, seems to prefer archiving them.
It's only really a guard against hardware failure, which I haven't seen on my computers except a single DVD burner (big deal, I lost only money and no data)
Then you are lucky. Hardware failure is not a matter of "if", it's a matter of "when".
more billing options - great, except consumers hate having to optimize depending on their changing usage scenarios.
Except as a customer, I love having the possibility of a pay-as-you-go model. Trials are nice, but why not let me test-drive the full product for less than a dollar? (Amazon EC2 is a good example.) And then, if I decide I like it, maybe a monthly fee is better, certainly less I have to think about. If I decide I don't like it, you just shut off my access, no need to worry about building complex and doomed DRM schemes to lock down the trial version after $NUM days.
control over your data - unless you consider your customers' data yours, I don't see how.
Unless it really is your data that you're exposing to your customers.
better security - you are running more potentially vulnerable applications than otherwise. How's that better security?
Because you are running those potentially vulnerable applications in a datacenter, managing them with IT professionals, and with clearly defined inputs and outputs.
A desktop app means you not only have to worry about your own app's security in the much harsher environment of the desktop, but you may have to worry about the security of the desktop itself.
However, looking at context, I suspect GP meant licensing security -- as in, again, no need for complex and doomed DRM, just kill their access.
licensing - Blizzard seemed to fail (there are (or were) no-pay servers working well with the no-pay trial client), despite slashdot saying companies should go that route.
Probably still are, not that it matters. Blizzard's value is in the network. Playing WoW on a pirate server is like insisting on using my own MySpace clone with 50 of my friends. Pointless -- the value of each is in the network effect. You play WoW on the legit servers because all your friends are, and because you've already made a bunch of new friends that way.
Besides which, just look at the numbers. Even if there are a few thousand pirates, there are ten million legitimate subscribers. How does that compare to any other PC game?
Can you search your mail on gmail for one containing an URL that matches a given list from a webcalendar ? No you can not, because you have no raw access on the data.
If that's the only obstacle, yes you can, because you have IMAP access. Which means if needed, you also have a copy of all your data.
But this isn't entirely about web apps that someone else needs to run...
Otherwise, I can use ssh and X11 forwarding and everything is fine
Unless you have a slow connection. Or an app which decides to crash, because the two versions of X11 are too different.
For that, the web is actually a much superior interface. And if you're the one writing the app (or using an open source one) and running it, I see no reason it "traps" you any more than any other GUI. Probably considerably less, if it's using a standard database like MySQL or SQLite, instead of its own format.
1) I don't really have anything useful to DO with lisp at the moment... Suggestions are welcome.
Get on a mailing list and watch for interesting things...
What I'm doing at the moment: Aside from work-related stuff, I'm also playing with Amazon EC2, and trying to write an actor library for Ruby. I love Ruby syntax, but I want Erlang concurrency -- but I hate Erlang syntax.
Another interesting project, if you're just looking for something to do: Reia. Someone is trying to implement a language incorporating ideas from scripting languages, like Ruby and Python, but running on top of the Erlang VM.
Another project I'd like to do, but simply don't have time for: Add recursive views for CouchDB. That is, views of views -- kind of like what I can do with Rails' named scopes on a SQL database.
2) I'm absolutely addicted to large screens and dual monitors. I am not sure how well I will be able to code on a laptop.
My laptop has a 1920x1200 resolution and HDMI out, which I plug into a 1080p 24" Dell monitor (cost $300 or so). That's a pretty nice dual-monitor setup.
If I cared, I suppose I would plug something into the VGA port. That'd be three monitors, or two if I decided to turn off the laptop monitor. But really, most laptops should have at least one video out. Laptop stand + external monitor/keyboard/mouse = dual monitors.
However, I also find that with virtual desktops and that much resolution, I don't actually need dual monitors. They're nice, but sometimes I like the convenience of coding on the couch, or in a coffee shop, or wherever.
Also worth mentioning: My laptop is currently my beefiest machine, so I actually am not in this boat of wanting a netbook connecting to a beefy desktop. Nice things about this are power efficiency and portability of a gaming machine (bring it to LAN parties instead of a desktop).
3) I am reluctant to turn my gaming rig into a unix box to act as the back end for fun coding projects.
Make it dual boot. Only boot Windows for games. What's the problem?
The dumb terminal was pretty dumb -- it would send individual keystrokes across the network, and wait for a response. If you scrolled, it had to redraw the screen.
A web browser can cache as much in RAM as we like, plus some disk cache. It can do audio and video, and a true GUI. It can do most things you would imagine a native client could do -- with Google Gears, that includes running offline.
And when your network connection died, the dumb terminal was useless. The netbook is still several orders of magnitude more powerful than the machine your dumb terminal would've been connecting to.
there's a reason we moved away from those.
Please, enlighten us. Then tell us why these reasons are still relevant.
But when you need to persist data, you have to spawn an ajax query and that 1/10 to 1/4 second (even over a fast network connection) just isn't comparable from the user perspective to hitting a local HD.
Or you use something like Google Gears... But let's pretend we have to do it your way, as there are some advantages anyway.
Notice the 'a' in 'ajax'? It stands for asynchronous -- as in, you don't have to wait, the UI remains responsive.
Besides, half of these things are going to be ad-supported, right?
No reason they have to be. Especially the open source ones -- I think there is some real value in having a beefy machine that you own somewhere, and accessing it with a netbook.
It's typical for a single page to load content, ads, local javascript, stylesheets, and analytics from 10 or more pages. Each of these connections triggers its own DNS query.
In other words, it could be poorly implemented, and it could be slow to load the first time, until that DNS is cached at your local machine, your ISP, their ISP, and so on all the way to the root servers.
Hah! Just reminded of a most annoying example! Slashdot, for me, loads pretty much instantly. But every time I post and click that "preview" button, there's a five-second wait before the preview actually shows up.
Again, a poorly-implemented example. There's no reason the "preview" function couldn't be done in Javascript. There's also no reason the "submit" function has to hide the preview, then scroll you back there when it's finished.
A better implementation might do the preview entirely in Javascript, and keep it the same size when submitting (plus maybe some floating status), so you could scroll down and keep reading while it tries to save.
Oh, and it's not five seconds. It's usually less than one, for me, unless there's something seriously wrong with my network.
However, I am curious about how one would go about compiling, or is it strictly code-editing, online-only apps?
I think that would be the idea -- for example, Heroku is all about editing Ruby On Rails apps. I'm also not entirely sure I see the point if your compiled program is an executable that you have to download...
A possibly debatable secondary reason is just that I don't want anyone else having access to my code that is potentially going to be released as closed source.
That is something you're going to have to live with, if your software is going to be a web application, unless you really want to start building your own datacenter.
The point of my post is that comparing to CakePHP is a lousy comparison, because a) CakePHP is a pretty minor player in the PHP world, and b) CakePHP is hideously slow.
Point b, I could have made about Rails -- and it's still not as slow as you would think.
Since I can't get people to actually watch the presentation, let me quote from it:
331 requests per second in a raw PHP app. Static HTML was 1327 rps.
Cake was barely 8, with acceleration.
Ruby, with a single mongrel, was 85 rps. With Passenger and Enterprise Ruby, 96 rps. So already, Rails is close enough that, worst case, you would have to run it on two machines instead of one.
Merb, with templates, was over a thousand rps, looks like over twelve hundred from the graph. I believe this was a different machine than the above, but I don't believe it was four times faster. It is the same machine, though, which is used for the rest of this comment.
There is also a comparison of static vs just the Merb router -- obviously, static is faster, but not by a huge amount. Then there's the controller versus php's echo -- almost exactly the same. And of course, the template -- already a very MVC-ish design -- is already better, by quite a lot, than CodeIgniter, and not much slower than php's echo.
Sinatra was almost two thousand rps -- slightly faster than a Merb controller.
No matter how you look at these benchmarks, the worst you can say is, "Rails is slow", and it's still not that slow. There is no way you can say "Ruby is slow", and there is certainly no way you can say that Merb is slow.
Oh, and Merb is going to be merged into Rails. Merb 2.0 is Rails 3.0.
The topic of framework vs no framework is another flamewar altogether, which I won't go into here.
Fair enough. I think you will agree, though, that it's much fairer to compare frameworks to frameworks, and no-framework to no-framework, than it is to compare a Ruby framework to raw PHP. (Even if the Merb happens to be almost as fast as raw PHP, and sometimes faster.)
It's a lot easier to simply, click a link on the Web page I already have open, but very rarely does that properly add the software in my package manager under Ubuntu.
I've found that this is actually less usable, in most cases, even on Windows. Best case, you've got something that allows you to run the executable from the browser -- which means at least one, sometimes two security prompts (one from Firefox, one from Windows, I wouldn't be surprised to see a third from UAC if I was on Vista) -- then click next-next-next.
Versus, check a box in add/remove programs, click "apply", done.
But you are right -- that is why I suggested that a frontend for OS X is about all that would be needed. After all, what you're describing is not a symptom of the package manager itself, but of the various frontends for it...
Package managers that are popular were designed to work with freeware and none I've seen contains any service for checking registration info or selling the software
In other words, none contain a DRM check.
Actually, what I've found to be the sanest method is to include a demo in the repository, and let the software itself manage actual license keys.
You're mistaking authenticating servers and authenticating software packages.
No, a GPG key authorizes whoever controls that key. There's no reason they couldn't distribute a signed package via CD, DVD, or a non-repository download.
Package managers need to handle software not just from repositories, but from other sources. If I download a.app "folder" in a DMG file,
You're already outside the package manager -- you should ideally have clicked a link that instructed your package manager to install something. But ok...
how is the package manager going to know where the repository to get updates is located? It either has to be able to contact a giant database of all software, or the.app folder needs to have data to tell it. That means an extension to current openstep bundle formats.
Exactly.
It's not hard to do, it just needs to be done.
So why are we still talking about this?
Ug, please no. I like it simple and applications self contained. When you start running scripts things get complicated and can break.
The fact that scripts aren't run means you're going to have people using another package format (like a.mpkg), or people running scripts on the app's first run.
And then how are you going to remove things like that menu it added to your menu bar?
Simple is good.
Simplicity from the user's perspective is good. But make things as simple as possible; no simpler.
I'm not suggesting that the majority of apps should have scripts run. I'm suggesting that some of them will need to run scripts, and some of them will have dependencies (which is part of the point).
You even have to consider applications designed for running in your VMs and APIs for other OS's
Having a package manager run on multiple OSes isn't really a big deal -- Rubygems is proof of that.
The other features you're talking about, I would say we have to go farther than that -- design a system which can handle things we haven't thought of yet.
This is probably getting a bit offtopic, but the simplest solution I can think of is to make the package manager pluggable, and specify whatever plugins you need as dependencies. Thus, if your package depends on package-manager-VM-plugin, it will have that functionality available once actually installed.
I guess I'm just not seeing the complexity, except in the UI itself, and we mostly know how that would look.
they get 37.46 requests/s for a hello world CakePHP page on a 3 GHz Intel machine with 512M RAM. I gave a plain PHP hello world page a try on a 1.3 GHz Pentium-M laptop
How much does either of those have to do with the real world? That's why I linked to a benchmark of a real (though simple) app, that actually reads and writes to a database...
I mean, I'm sure I can beat your scores with a static page.
What matters is, when you actually start to build out your application's logic, how much do you have to rewrite yourself that you could have borrowed from something like Cake? Are you sure you're doing it more efficiently than Cake would be?
By the time you've built your own router, controllers, models, and ORM, you may find your app is slower than a Cake (or Rails) app. That is -- by the time your app is doing more interesting things than "Hello World".
Wake me up with RoR (or Ruby) is faster than stock PHP.
Wake up, then, and follow the link I pasted, way up in this thread. If you really don't need a heavyweight MVC architecture, you can use the bare Merb router, or a bare-metal Rack app. Sinatra might even be a good balance.
Rails vs Cake is a fair comparison, as both are frameworks. Rack against PHP would be much closer.
Now, your turn. Why should I care about stock PHP? Why would I want to go back to not using a framework? Show me a PHP framework that's as fast as Rails, and I might be interested -- except, of course, Ruby is still a nicer language to work with.
Not that those things are irrelevant, just that initially, they are less important.
Certainly, it's possible eBay could save a lot of money on hardware by rewriting the site in a faster language (or even in C) if they started in Bash. It's also possible they would start looking at other optimizations -- all those little hacks you avoid during development could suddenly mean thousands of dollars saved.
But you won't know which hacks are worth thousands of dollars, and which ones will cause thousands of dollars in debugging headaches for no real gain, without profiling. And it's kind of difficult to profile before you have a working site.
For OS X and Windows the components are only there if you are ignoring other software installation methods and locations, such as installation from a Web page, arguably the most common use case.
And that is a flaw in the Windows software ecosystem.
It's worth mentioning that the same works elsewhere -- I can download an installer binary from a website and run it. The problem is, on Windows and OS X, there really isn't a good alternative.
They easily allow third party repositories that are appropriate for free software, but not so much for commercial payware.
It can't be that hard to allow the files to come from an arbitrary URL, can it? That depends upon if you care about security I suppose. OS X and Vista have signing frameworks
So do open source repositories. They generally use PGP, as it's easier to manage without having to pay absurd signing keys.
Which means that you set up the repository once, and you obtain a key for it. After that, assuming the key was correct, the software itself can come from any arbitrary URL, as long as the repository maintainer has signed it.
The frustrating thing is, decent package managers already exist. Why not just write a frontend for them?
I's argue that most package managers these days don't have very good usability for the average user.
Perhaps, but they are the best we've got.
And that is why I suggested writing a frontend. I see no reason something like dpkg/apt can't be used, given a sufficiently usable (and pretty) frontend.
Apple has some distinct advantages with their "software is a folder" model, but it also means a lot more work to adapt package managers to work well with that style of software.
That makes sense... Wait, what?
Traditional package managers tend to distribute packages as single files, containing both package metadata and an archive. That archive contains many files, in many directories -- also known as folders -- and Apple has certainly shown that it can embed metadata in formats like Zip. In fact, I know I've seen OS X.app files distributed as zipfiles.
So, in what way would a package manager make that difficult?
Of course, the better approach might be to put package metadata inside the.app folder, and simply distribute them as zips or dmgs, with a central listing. But then you lose the functionality you get with a good package manager (or even an ok one, like mpkg), which is why I suspect the best approach would be for Apple to simply enhance the Finder view of the Applications folder -- drag an app to the trash, and it runs an uninstall script, if present.
It's just not quite as straightforward as you seem to imply
It's very straightforward.
The only part that's not straightforward is making it usable, making it more convenient than downloading a dmg/zip, and getting people interested, even excited. But Apple is very good at that -- they even made backup sexy, so I see no reason they couldn't do the same to package management.
Usually they also handle discovery, installation, and uninstallation as well. Ideally, they would also handle software registration and other universal functions.
That is true. However, all of the components are there -- on OS X, in mpkg; on Windows, in MSI.
Apple and MS could allow third parties to update software through updater, but currently they would have to host all that data and pay for the bandwidth.
It can't be that hard to allow the files to come from an arbitrary URL, can it?
Additionally, they would have to perform some level of testing and security auditing lest they be blamed for malware or misconfigurations.
On some level, yes -- although it's worth mentioning, Apple does this with the App Store. All that's needed is to open it up to third parties, with an appropriate warning -- for example, Ubuntu easily allows third-party repositories, but it's unlikely Canonical will support any of them.
The frustrating thing is, decent package managers already exist. Why not just write a frontend for them?
Actually, compared to PHP, it is slow. Alot of people benchmark PHP incorrectly. Everyone who knows anything about PHP knows it was built to be an Apache module and never to be used as a command line utility because it doesn't have a daemon
Then you might be surprised by the benchmark I actually linked to. This was a measure in requests per second of a full Web application, not of something silly like fibbonacci.
Nuby developers love to quote this stat but are clueless in the fact that what they are quoting is completely wrong.
Once again: Look at the actual statistic I'm quoting. Are you suggesting this was CakePHP, run as a web app, benchmarked with a web benchmark, yet somehow run as a commandline app?
Slashdot Mirror
Google is a problem, but not nearly as much.
You do get one account for all Google services.
Apps do work better with GMail. Their calendar and mail, in particular, are somewhat more tightly integrated than you might want -- and invitations to a calendar event pretty much only work with a Google account, even if the recipient doesn't use Google Calendar.
I'm sure I could find other things if I tried. Some of these would be hard to do in a more open fashion. All of them do, in subtle ways, suggest that you use more Google services.
And there are the privacy issues, but that's separate from the monopoly issues.
I agree, though, Google is not a huge problem. For all the control they appear to have, there's still quite a lot of opportunity to just not use them. Even if you absolutely need that YouTube video, you can always kill tracking cookies.
Microsoft, on the other hand, is nearly impossible to avoid.
they'd gain back some of the epic amounts of geek credibility they lost during the OOXML debacle
Some. The OOXML debacle is only the latest in a very long line of typically Microsoft practices.
Their geek cred has fallen a long way. Just as they would have to do everything wrong for over a decade before money was an issue, they'd have to do everything right for over a decade to earn back the respect they've lost for pretty much their entire existence.
Really, what do you think a judge can do about it anyway?
Acknowledge it, maybe? Instead of brushing it aside and attacking their competitor, showing clear favoritism?
What's done is done.
In the case of bundling IE vs Netscape, yes. Does that mean they can't still be prosecuted for their many (broken MS Java), many (per-unit licensing vs per-Windows-unit for OEMs), many (OpenXML and ISO) predatory business practices?
And yet, this is the woman who says Microsoft is "so last century". It's difficult to think of a market harder to enter than the desktop OS market, or the office productivity suite market.
For me, Microsoft is so last century. They are not the problem.
I don't know about you, but my father uses Windows. My mother uses Windows, except for an old machine I've set up for her music library on Linux. My brother uses Windows. His friends all use Windows. Most of my friends use Windows, except the few who have Macs -- and those run Windows in a VM.
Even I use Windows -- VM or dual boot.
I've finally reached a point in my life where I don't have to touch Windows more than once a week, unless I want to play a game. And yet, I still can't design web apps the way I want -- I still have to either force everyone to download Firefox, or spend around 10% extra development time supporting Internet Explorer. (And I can't develop IE-only, or I don't have Firebug.)
If you don't see Microsoft as a problem, you aren't looking. If you see them as "so last century", it's because you let them get away with it last century!
I'm not going to defend Google, but that statement is dangerous thinking. Just because everyone forgot about the problem doesn't mean it's gone.
Isn't building that one golden application that pays for your datacenter so you can unleash your other mad-scientist type plans on the world the holy grail, so to speak?
Except that while building that application, you really don't want to be hosting it out of your garage.
So yes, it would start on my own hardware -- as in, my laptop. Then, if I wanted it to be remotely serious, I'd put it up on Slicehost and let them take backups. If I started getting some serious traffic, I'd branch out to Amazon EC2 and S3.
Then, once I've actually built the next eBay or whatever, it might be worth considering building my own datacenter. But it's just not cost-effective for a small app -- I don't even need an entire machine, and I certainly don't want to be buying several machines (and several network connections, for redundancy), UPS, cooling, etc, when I'm still effectively a Mom&Pop operation.
I mean, I get it -- it would be cool to have all that stuff. But it would be a lot of work to maintain, and it'd be a waste of money, considering the alternatives.
Last I checked, IE8 was still far behind everyone else in standards compliance, and that's with the same standards (XHTML, CSS, JavaScript) that have been with us for a decade. That says nothing of the brand-new standards people are inventing (HTML5, SVG/canvas) which IE hasn't even touched.
I place the blame squarely on IE for the amount of Flash we have now.
And yet, they're breaking enough compatibility that Google.com (and Microsoft.com) won't render properly. Which means they've chosen to make IE8 another IE7 -- break tons of compatibility, probably introduce tons of new UI for no good reason, yet still be the least compliant browser in existence.
The smartest thing for them to do would be to break compatibility entirely, and start with something that's gotten it right -- Webkit or Gecko.
and Direct3D for what's still left of Microsoft Windows and believe me when I say Linux and Apple are going to kill Windows
That makes the rest of your post hard to take seriously. Five years? Really?
You know, as bad as Vista was, people bought it. As bad as Direct3D was when it started out, it's actually to the point where many people seem to prefer it to OpenGL.
With a typical power usage in the 30-70 watts.
The whole machine can use a maximum of 90 watts, and tends to run just fine with a 60 watt adapter.
That's maximum. Typically, it's more like 20 watts -- again, for the whole machine, including a monitor.
Right now, for HD video, it might matter. In 5 years, it won't. Put another way, I used to actually care, and research, how much CPU a given piece of hardware might need -- or how much might be offloaded to, say, a network card. Used to be, hardware RAID had a point, too.
Now, it really doesn't matter -- CPUs are fast enough that it's cheaper to buy (and operate) a 10% faster CPU than it is to buy a RAID card.
I'm guessing the same will happen for HD video. As for games, we already know how that goes -- at a certain point, raytracing scales better than rasterization.
Worse than that, it seems to be about the vulnerabilities of not using SSL, not anything inherent in SSL itself.
Unless I'm mistaken, the only vulnerability in redirecting all HTTP traffic to HTTPS is that users might type paypal.com, end up on https://paypals.com/ and not notice.
Sensationalist, as usual.
Granted, most sites are still quite a bit worse off than that -- forms served over HTTP that send your password over HTTPS -- but as usual, there are simple workarounds. For example, bookmark https://mail.google.com/ -- problem solved for Gmail.
more power - no, the server controls your data and you have to be the kind of person who knows what a web scraper is and how to write one to get it out without spending $BIGNUM hours.
I think this is probably talking about things like the universal access. After all, the amount of additional power you'd have out of having the data locally is again relative to if you're the kind of person who knows how to write data mining software.
reliability - depends on whether you're better at managing your local app than the bottleneck of you managing to always have a connection and them managing the app.
Almost no one is good at managing a local app. Ask ten people if they do backups -- I bet nine of them will say "no".
And you don't really have to. Your connection dies, you pick up a laptop and go to a coffee shop. Problem solved -- or at least, now it's your ISP's problem.
centralized support - whether that's good depends on how good support you can get. Your mom is going to prefer good support from you rather than mediocre support from "Robert" who works in Calcutta.
And I'd prefer she talks to Robert, whose job it is to help her. Either way, chances are she'll have fewer problems to begin with.
if you delete a mail from your yahoo mail account, can you get it back?
Probably not. That's why it's not generally easy to delete things -- Gmail, at least, seems to prefer archiving them.
It's only really a guard against hardware failure, which I haven't seen on my computers except a single DVD burner (big deal, I lost only money and no data)
Then you are lucky. Hardware failure is not a matter of "if", it's a matter of "when".
more billing options - great, except consumers hate having to optimize depending on their changing usage scenarios.
Except as a customer, I love having the possibility of a pay-as-you-go model. Trials are nice, but why not let me test-drive the full product for less than a dollar? (Amazon EC2 is a good example.) And then, if I decide I like it, maybe a monthly fee is better, certainly less I have to think about. If I decide I don't like it, you just shut off my access, no need to worry about building complex and doomed DRM schemes to lock down the trial version after $NUM days.
control over your data - unless you consider your customers' data yours, I don't see how.
Unless it really is your data that you're exposing to your customers.
better security - you are running more potentially vulnerable applications than otherwise. How's that better security?
Because you are running those potentially vulnerable applications in a datacenter, managing them with IT professionals, and with clearly defined inputs and outputs.
A desktop app means you not only have to worry about your own app's security in the much harsher environment of the desktop, but you may have to worry about the security of the desktop itself.
However, looking at context, I suspect GP meant licensing security -- as in, again, no need for complex and doomed DRM, just kill their access.
licensing - Blizzard seemed to fail (there are (or were) no-pay servers working well with the no-pay trial client), despite slashdot saying companies should go that route.
Probably still are, not that it matters. Blizzard's value is in the network. Playing WoW on a pirate server is like insisting on using my own MySpace clone with 50 of my friends. Pointless -- the value of each is in the network effect. You play WoW on the legit servers because all your friends are, and because you've already made a bunch of new friends that way.
Besides which, just look at the numbers. Even if there are a few thousand pirates, there are ten million legitimate subscribers. How does that compare to any other PC game?
Can you search your mail on gmail for one containing an URL that matches a given list from a webcalendar ? No you can not, because you have no raw access on the data.
If that's the only obstacle, yes you can, because you have IMAP access. Which means if needed, you also have a copy of all your data.
But this isn't entirely about web apps that someone else needs to run...
Otherwise, I can use ssh and X11 forwarding and everything is fine
Unless you have a slow connection. Or an app which decides to crash, because the two versions of X11 are too different.
For that, the web is actually a much superior interface. And if you're the one writing the app (or using an open source one) and running it, I see no reason it "traps" you any more than any other GUI. Probably considerably less, if it's using a standard database like MySQL or SQLite, instead of its own format.
1) I don't really have anything useful to DO with lisp at the moment... Suggestions are welcome.
Get on a mailing list and watch for interesting things...
What I'm doing at the moment: Aside from work-related stuff, I'm also playing with Amazon EC2, and trying to write an actor library for Ruby. I love Ruby syntax, but I want Erlang concurrency -- but I hate Erlang syntax.
Another interesting project, if you're just looking for something to do: Reia. Someone is trying to implement a language incorporating ideas from scripting languages, like Ruby and Python, but running on top of the Erlang VM.
Another project I'd like to do, but simply don't have time for: Add recursive views for CouchDB. That is, views of views -- kind of like what I can do with Rails' named scopes on a SQL database.
2) I'm absolutely addicted to large screens and dual monitors. I am not sure how well I will be able to code on a laptop.
My laptop has a 1920x1200 resolution and HDMI out, which I plug into a 1080p 24" Dell monitor (cost $300 or so). That's a pretty nice dual-monitor setup.
If I cared, I suppose I would plug something into the VGA port. That'd be three monitors, or two if I decided to turn off the laptop monitor. But really, most laptops should have at least one video out. Laptop stand + external monitor/keyboard/mouse = dual monitors.
However, I also find that with virtual desktops and that much resolution, I don't actually need dual monitors. They're nice, but sometimes I like the convenience of coding on the couch, or in a coffee shop, or wherever.
Also worth mentioning: My laptop is currently my beefiest machine, so I actually am not in this boat of wanting a netbook connecting to a beefy desktop. Nice things about this are power efficiency and portability of a gaming machine (bring it to LAN parties instead of a desktop).
3) I am reluctant to turn my gaming rig into a unix box to act as the back end for fun coding projects.
Make it dual boot. Only boot Windows for games. What's the problem?
The dumb terminal was pretty dumb -- it would send individual keystrokes across the network, and wait for a response. If you scrolled, it had to redraw the screen.
A web browser can cache as much in RAM as we like, plus some disk cache. It can do audio and video, and a true GUI. It can do most things you would imagine a native client could do -- with Google Gears, that includes running offline.
And when your network connection died, the dumb terminal was useless. The netbook is still several orders of magnitude more powerful than the machine your dumb terminal would've been connecting to.
there's a reason we moved away from those.
Please, enlighten us. Then tell us why these reasons are still relevant.
But when you need to persist data, you have to spawn an ajax query and that 1/10 to 1/4 second (even over a fast network connection) just isn't comparable from the user perspective to hitting a local HD.
Or you use something like Google Gears... But let's pretend we have to do it your way, as there are some advantages anyway.
Notice the 'a' in 'ajax'? It stands for asynchronous -- as in, you don't have to wait, the UI remains responsive.
Besides, half of these things are going to be ad-supported, right?
No reason they have to be. Especially the open source ones -- I think there is some real value in having a beefy machine that you own somewhere, and accessing it with a netbook.
It's typical for a single page to load content, ads, local javascript, stylesheets, and analytics from 10 or more pages. Each of these connections triggers its own DNS query.
In other words, it could be poorly implemented, and it could be slow to load the first time, until that DNS is cached at your local machine, your ISP, their ISP, and so on all the way to the root servers.
Hah! Just reminded of a most annoying example! Slashdot, for me, loads pretty much instantly. But every time I post and click that "preview" button, there's a five-second wait before the preview actually shows up.
Again, a poorly-implemented example. There's no reason the "preview" function couldn't be done in Javascript. There's also no reason the "submit" function has to hide the preview, then scroll you back there when it's finished.
A better implementation might do the preview entirely in Javascript, and keep it the same size when submitting (plus maybe some floating status), so you could scroll down and keep reading while it tries to save.
Oh, and it's not five seconds. It's usually less than one, for me, unless there's something seriously wrong with my network.
However, I am curious about how one would go about compiling, or is it strictly code-editing, online-only apps?
I think that would be the idea -- for example, Heroku is all about editing Ruby On Rails apps. I'm also not entirely sure I see the point if your compiled program is an executable that you have to download...
A possibly debatable secondary reason is just that I don't want anyone else having access to my code that is potentially going to be released as closed source.
That is something you're going to have to live with, if your software is going to be a web application, unless you really want to start building your own datacenter.
Watching an HD video does, and the CPU is horrible at it.
Maybe relatively. It might even matter in a laptop...
On a modern dual-core 2.5 ghz CPU, I can play HD video fullscreen, 1080p, smoothly.
So the real question is whether manycore is really that much more expensive or wasteful than decent specialized chips.
The point of my post is that comparing to CakePHP is a lousy comparison, because a) CakePHP is a pretty minor player in the PHP world, and b) CakePHP is hideously slow.
Point b, I could have made about Rails -- and it's still not as slow as you would think.
Since I can't get people to actually watch the presentation, let me quote from it:
331 requests per second in a raw PHP app. Static HTML was 1327 rps.
Cake was barely 8, with acceleration.
Ruby, with a single mongrel, was 85 rps. With Passenger and Enterprise Ruby, 96 rps. So already, Rails is close enough that, worst case, you would have to run it on two machines instead of one.
Merb, with templates, was over a thousand rps, looks like over twelve hundred from the graph. I believe this was a different machine than the above, but I don't believe it was four times faster. It is the same machine, though, which is used for the rest of this comment.
There is also a comparison of static vs just the Merb router -- obviously, static is faster, but not by a huge amount. Then there's the controller versus php's echo -- almost exactly the same. And of course, the template -- already a very MVC-ish design -- is already better, by quite a lot, than CodeIgniter, and not much slower than php's echo.
Sinatra was almost two thousand rps -- slightly faster than a Merb controller.
No matter how you look at these benchmarks, the worst you can say is, "Rails is slow", and it's still not that slow. There is no way you can say "Ruby is slow", and there is certainly no way you can say that Merb is slow.
Oh, and Merb is going to be merged into Rails. Merb 2.0 is Rails 3.0.
The topic of framework vs no framework is another flamewar altogether, which I won't go into here.
Fair enough. I think you will agree, though, that it's much fairer to compare frameworks to frameworks, and no-framework to no-framework, than it is to compare a Ruby framework to raw PHP. (Even if the Merb happens to be almost as fast as raw PHP, and sometimes faster.)
It's a lot easier to simply, click a link on the Web page I already have open, but very rarely does that properly add the software in my package manager under Ubuntu.
I've found that this is actually less usable, in most cases, even on Windows. Best case, you've got something that allows you to run the executable from the browser -- which means at least one, sometimes two security prompts (one from Firefox, one from Windows, I wouldn't be surprised to see a third from UAC if I was on Vista) -- then click next-next-next.
Versus, check a box in add/remove programs, click "apply", done.
But you are right -- that is why I suggested that a frontend for OS X is about all that would be needed. After all, what you're describing is not a symptom of the package manager itself, but of the various frontends for it...
Package managers that are popular were designed to work with freeware and none I've seen contains any service for checking registration info or selling the software
In other words, none contain a DRM check.
Actually, what I've found to be the sanest method is to include a demo in the repository, and let the software itself manage actual license keys.
You're mistaking authenticating servers and authenticating software packages.
No, a GPG key authorizes whoever controls that key. There's no reason they couldn't distribute a signed package via CD, DVD, or a non-repository download.
Package managers need to handle software not just from repositories, but from other sources. If I download a .app "folder" in a DMG file,
You're already outside the package manager -- you should ideally have clicked a link that instructed your package manager to install something. But ok...
how is the package manager going to know where the repository to get updates is located? It either has to be able to contact a giant database of all software, or the .app folder needs to have data to tell it. That means an extension to current openstep bundle formats.
Exactly.
It's not hard to do, it just needs to be done.
So why are we still talking about this?
Ug, please no. I like it simple and applications self contained. When you start running scripts things get complicated and can break.
The fact that scripts aren't run means you're going to have people using another package format (like a .mpkg), or people running scripts on the app's first run.
And then how are you going to remove things like that menu it added to your menu bar?
Simple is good.
Simplicity from the user's perspective is good. But make things as simple as possible; no simpler.
I'm not suggesting that the majority of apps should have scripts run. I'm suggesting that some of them will need to run scripts, and some of them will have dependencies (which is part of the point).
You even have to consider applications designed for running in your VMs and APIs for other OS's
Having a package manager run on multiple OSes isn't really a big deal -- Rubygems is proof of that.
The other features you're talking about, I would say we have to go farther than that -- design a system which can handle things we haven't thought of yet.
This is probably getting a bit offtopic, but the simplest solution I can think of is to make the package manager pluggable, and specify whatever plugins you need as dependencies. Thus, if your package depends on package-manager-VM-plugin, it will have that functionality available once actually installed.
I guess I'm just not seeing the complexity, except in the UI itself, and we mostly know how that would look.
they get 37.46 requests/s for a hello world CakePHP page on a 3 GHz Intel machine with 512M RAM. I gave a plain PHP hello world page a try on a 1.3 GHz Pentium-M laptop
How much does either of those have to do with the real world? That's why I linked to a benchmark of a real (though simple) app, that actually reads and writes to a database...
I mean, I'm sure I can beat your scores with a static page.
What matters is, when you actually start to build out your application's logic, how much do you have to rewrite yourself that you could have borrowed from something like Cake? Are you sure you're doing it more efficiently than Cake would be?
By the time you've built your own router, controllers, models, and ORM, you may find your app is slower than a Cake (or Rails) app. That is -- by the time your app is doing more interesting things than "Hello World".
Wake me up with RoR (or Ruby) is faster than stock PHP.
Wake up, then, and follow the link I pasted, way up in this thread. If you really don't need a heavyweight MVC architecture, you can use the bare Merb router, or a bare-metal Rack app. Sinatra might even be a good balance.
Rails vs Cake is a fair comparison, as both are frameworks. Rack against PHP would be much closer.
Now, your turn. Why should I care about stock PHP? Why would I want to go back to not using a framework? Show me a PHP framework that's as fast as Rails, and I might be interested -- except, of course, Ruby is still a nicer language to work with.
Not that those things are irrelevant, just that initially, they are less important.
Certainly, it's possible eBay could save a lot of money on hardware by rewriting the site in a faster language (or even in C) if they started in Bash. It's also possible they would start looking at other optimizations -- all those little hacks you avoid during development could suddenly mean thousands of dollars saved.
But you won't know which hacks are worth thousands of dollars, and which ones will cause thousands of dollars in debugging headaches for no real gain, without profiling. And it's kind of difficult to profile before you have a working site.
For OS X and Windows the components are only there if you are ignoring other software installation methods and locations, such as installation from a Web page, arguably the most common use case.
And that is a flaw in the Windows software ecosystem.
It's worth mentioning that the same works elsewhere -- I can download an installer binary from a website and run it. The problem is, on Windows and OS X, there really isn't a good alternative.
They easily allow third party repositories that are appropriate for free software, but not so much for commercial payware.
Canonical does this.
It can't be that hard to allow the files to come from an arbitrary URL, can it?
That depends upon if you care about security I suppose. OS X and Vista have signing frameworks
So do open source repositories. They generally use PGP, as it's easier to manage without having to pay absurd signing keys.
Which means that you set up the repository once, and you obtain a key for it. After that, assuming the key was correct, the software itself can come from any arbitrary URL, as long as the repository maintainer has signed it.
The frustrating thing is, decent package managers already exist. Why not just write a frontend for them?
I's argue that most package managers these days don't have very good usability for the average user.
Perhaps, but they are the best we've got.
And that is why I suggested writing a frontend. I see no reason something like dpkg/apt can't be used, given a sufficiently usable (and pretty) frontend.
Apple has some distinct advantages with their "software is a folder" model, but it also means a lot more work to adapt package managers to work well with that style of software.
That makes sense... Wait, what?
Traditional package managers tend to distribute packages as single files, containing both package metadata and an archive. That archive contains many files, in many directories -- also known as folders -- and Apple has certainly shown that it can embed metadata in formats like Zip. In fact, I know I've seen OS X .app files distributed as zipfiles.
So, in what way would a package manager make that difficult?
Of course, the better approach might be to put package metadata inside the .app folder, and simply distribute them as zips or dmgs, with a central listing. But then you lose the functionality you get with a good package manager (or even an ok one, like mpkg), which is why I suspect the best approach would be for Apple to simply enhance the Finder view of the Applications folder -- drag an app to the trash, and it runs an uninstall script, if present.
It's just not quite as straightforward as you seem to imply
It's very straightforward.
The only part that's not straightforward is making it usable, making it more convenient than downloading a dmg/zip, and getting people interested, even excited. But Apple is very good at that -- they even made backup sexy, so I see no reason they couldn't do the same to package management.
Usually they also handle discovery, installation, and uninstallation as well. Ideally, they would also handle software registration and other universal functions.
That is true. However, all of the components are there -- on OS X, in mpkg; on Windows, in MSI.
Apple and MS could allow third parties to update software through updater, but currently they would have to host all that data and pay for the bandwidth.
It can't be that hard to allow the files to come from an arbitrary URL, can it?
Additionally, they would have to perform some level of testing and security auditing lest they be blamed for malware or misconfigurations.
On some level, yes -- although it's worth mentioning, Apple does this with the App Store. All that's needed is to open it up to third parties, with an appropriate warning -- for example, Ubuntu easily allows third-party repositories, but it's unlikely Canonical will support any of them.
The frustrating thing is, decent package managers already exist. Why not just write a frontend for them?
Actually, compared to PHP, it is slow. Alot of people benchmark PHP incorrectly. Everyone who knows anything about PHP knows it was built to be an Apache module and never to be used as a command line utility because it doesn't have a daemon
Then you might be surprised by the benchmark I actually linked to. This was a measure in requests per second of a full Web application, not of something silly like fibbonacci.
Nuby developers love to quote this stat but are clueless in the fact that what they are quoting is completely wrong.
Once again: Look at the actual statistic I'm quoting. Are you suggesting this was CakePHP, run as a web app, benchmarked with a web benchmark, yet somehow run as a commandline app?