It's like the rest of the OS -- it works for some things, not for others.
However, occasionally, what you need and what Wine/Linux provides sync up perfectly. Then, there are a lot of good reasons to switch -- free-as-in-beer being the obvious one.
As an example: I have tried plenty of programs in Wine, and watched them fail horribly. Others, I simply don't want to sacrifice a dozen FPS and some visual quality to play Portal on Linux, when I can just keep an XP partition around.
But every now and then, you end up with something like Filemaker or Quicken working just perfectly -- and if the only remaining app a user depends on is in that list, they can pretty much stop booting Windows.
Even if Wine never "catches up", every user who can use Wine instead of Windows is a win. And those users who do make the switch aren't likely to switch back because of a new app that isn't supported -- they're more likely to try to get it supported, or seek out another app.
So, even in a perfect world, where Linux achieves at least some 20 or 30% marketshare, to where people can no longer ignore it (and possibly starting a tidal wave of Windows users jumping ship), Wine probably wouldn't be perfect. But it would be enough to drive demand, and change the game.
How many developers want to put in the extra effort for a 0.1% wider audience?
Developers who find actual numbers, instead of pulling them out of their ass.
And that means doing a little market research. The market for your app may be biased one way or the other. For instance, if you're selling a text editor targeted at programmers -- or better yet, an SCM -- it's probably not too difficult to port, and you'll probably get quite a few grateful Linux users.
consider the Linux crowd has the "free (as in beer) software mentality"....
Can we get past this already? It seems the only Linux folk who have that mentality are complete strawmen created by people who've never actually met a Linux user.
I actually bought Windows XP, despite Linux being my primary OS. Most Windows users I know will pirate it if it didn't come with the machine.
There is one exception to that rule: On Windows, there are tons of little freeware (but closed source) utilities like IrfanView, WinRAR, etc. On Windows, and to a larger extent, OS X, there's even more -- a massive culture of shareware, where tiny cataloging utilities and file management utilities are selling for $10 to $20 each.
So, if your app is something truly useful, sure. I would love to see things like Photoshop support Wine officially (I'll use Gimp when I can, but it still hasn't caught up), and I love that WoW releases Wine-specific patches, and Eve uses Winelib.
But if you're trying to sell me a $15 version of diff or merge, it had better iron my socks, too.
The problem is, over the years, I start to find that my original naming scheme no longer appeals to me, so when I get a new box, it usually ends up with a different name.
The first with a proper name was a desktop: Morpheus (after the Matrix character). Next was a laptop: Trinity.
Then I got sick of The Matrix, so when I bought two desktops, one to use as a headless server (fileserver, mailserver, etc), I used Halo names: Grunt (server) and Elite (desktop).
I got a Mac, and decided it should have a wholly different name -- Eve, after the Applegeeks robot.
And now I have a shiny new Dell laptop running Ubuntu, named Serenity, after everyone's favorite Firefly-class transport.
Plus a Slicehost slice named Kernel...
I've worked at places that had consistent naming schemes, and those were worse -- one was based on metallurgy, so servers had names like Cobalt, Chromium, Molybdenum, etc. Cobalt was fine, Chromium was fine, but to type (and remember!) Molybdenum was pushing it. As confusing as my own naming scheme is, at least they're all relatively easy words.
Batchfiles are Turing-complete, I'm fairly sure. And anything you can't do from there means the program itself likely hasn't exposed that functionality via the commandline.
Linux shell scripts are getting there but still not as nice... Sending commands directly to applications would be the big change.
I can do that. It's called dbus. Among other things, I can execute Javascript within any Konqueror window, I can pause/play Amarok, and I can pull passwords out of kwallet.
'winamp.stop', 'mplayer.openfile('C:MyMovies')' are examples.
Yep. I can do that.
I think the whole batch file system windows has should be replaced by a new system.
Like PowerShell?
Atm to get teh script i wrote above to work i'd have to get plugins for winamp and wmp... and since one doesnt exist for wmp i'd have to code that.
Or use something other than windows media player.
Either way batchfiles are NOT for the regular user, I bet half of my second year CS class has never used one.
I think that says more about your CS class than it does about batchfiles. I don't know a single programmer who doesn't at least use a few.
You could start one program, close it, then start another and still have a standard UI between them.
Which is still not a standard GUI to manage them, and a GUI is a big deal.
Windows didn't get true multitasking till NT, before that programs were pretty much put on hold till they were focused on again.
And yet, as a user, I wouldn't care nearly as much about boring details like that -- multicore wasn't at all common, then.
Seriously, given the choice between running exactly one application at a time, and having to type a command to open it, then close it and switch to another...
Versus being able to simply leave several programs open, and switch between them with alt+tab?
True or not, multitasking is a huge deal, as much so as the GUI aspect. I'd rather run any version of Windows than DOS, unless I can cheat by running loadlin.exe or win.exe.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
if usage grows much faster than the complexity of the application, you eventually have to address the problem with programmers rather than hardware, especially if your business model doesn't involve profits growing linearly with usage.
However, there should be some amount of profit which improves linearly -- why wouldn't you throw some Google ads on the site?
As for usage growing faster than complexity, we generally call this "A nice problem to have."
Now I'm not saying that our case is the norm...far from it.
And I'll concede that there are many situations outside the norm, which is why I would love to see Ruby get faster. I see nothing in the syntax and behavior of either language to suspect that Java should automatically be faster than Ruby.
But for now, there's still embedded systems, mainframes, operating system kernels, console video games, and many, many other places where a language like Ruby isn't even remotely appropriate.
I will make one more argument: Every greenfield app should probably at least be prototyped in something like Ruby. If you find yourself in a situation like you've described, you can always rewrite in another language. But since it's a greenfield app, what you want to avoid is letting a competitor get their version out the door before yours, even if your version is more efficient than theirs.
I'm curious whether you considered JRuby?
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
The idiom of "let's throw more hardware at the problem" is a way of saying "we don't know jack shit about how to build a scalable web application,
You're misusing the word "scalable". You probably mean vertical scalability, or performance.
And it's not saying we don't know how to build a performant application. It's saying we don't care, because programmer time is more expensive than CPU time. It's simply not worth it to optimize past a certain point.
you're looking for a miracle since it's a known fact RoR doesn't scale very well.
Citation needed.
Also, you are again talking about vertical scalability. Rails is actually excellent at horizontal scalability, which means, specifically, "Can we throw more servers at it and have it just work?"
Not every PHP app can do that. Nor every Python, or Java app. However, unless you do something stupid, every Rails app can be scaled by throwing hardware at it.
Keep in mind, you will have to do this at some point. No Amazon, or Myspace, or Google, is going to run off a single server, no matter how massive. They all have to scale horizontally. You have to address that problem sooner or later.
So, I'm arguing that horizontal scalability is more important than vertical scalability. Horizontal scalability means you can ultimately handle as much traffic as you can find hardware for. Vertical scalability means you save some money on hardware -- that's all.
just following the RoR hype of it being the best thing since sliced bread, which it's not.
No, it's not, but it's still pretty damned good.
Hype does not automatically make something a bad idea. Does anyone remember the hype about AJAX? I think most Rails hype is tame compared to that, but as it turned out, AJAX is pretty useful. It's not the Best Thing Ever, but it's still useful.
If you can find where I've said Rails is the best thing ever, please, point it out. Otherwise, please try to reply to just my post, not every Rails developer ever.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
Why would I as a business be expected to switch to a language that requires twice as much hardware?
Because it requires half as many programmers, and hardware is far cheaper than programmers.
What you MAY save with software dev speed, you now lose with day to day server maintenance.
Server maintenance? Ah, I see, you're well behind the times.
See, I can fire up another Amazon EC2 instance with a single command, or automatically from a script. And since I assemble and manage them with scripts, once I get it past a single instance, it takes exactly as much effort to manage twenty as it does to manage two.
And your comment about "moving parts" is equally dated, if you're thinking in terms of likelihood for a CPU to fail. Once I've got two, if either fails, the other can notice and fire up a new instance, killing that one. Failing hardware then becomes Amazon's problem, not mine.
And seriously, day to day maintenance? Haven't touched the 3mix server in over a week. If you have to perform manual maintenance on a production server every day, you're Doing It Wrong.
The key to good engineering is to simplify because the more parts, the more chance of failure.
This is true of code, also. Fewer lines of code means fewer moving parts. Ruby commonly means fewer lines of code.
when similar languages such as PHP, PERL and PYTHON can do it with far less hardware is not a very good solution.
Can they, though? Follow the link in the post you're replying to. Ruby is not significantly slower than PHP in real-world benchmarks -- in a few of them, it's significantly faster.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
So basically you're pissed that your hobby language (and make no mistake, that's all Ruby will ever be)
there are more "unimaginative programmers" who know it thus allowing business to move forward with doing actual in an attempt to make a profit.
That is why I tend to move towards small businesses and startups. You don't need those "more programmers" -- you need the five or ten programmers it will take to get the job done. More than that is just people warming seats.
But then, PHP makes it so easy to botch the job the first time, you can pretty much guarantee there will be more programmers back to warm seats.
And no, I'm not really pissed about it. Actually, I'm happy about it. See, I know PHP, so I can use it if I have to. I also know Ruby, and there are fewer people who know Ruby. That makes me valuable -- and it makes the one startup out of twenty that's using Ruby instead of PHP that much more likely to succeed.
You'll always a cog in the machine.
I've never been a cog in the machine, not in my working adult life.
You don't understand business, that much is obvious.
I'm not paid to. I'm paid to write good code, which I can do more effectively and more productively in Ruby than in PHP.
Except that slideshow is comparing the performance of popular frameworks for different languages.
I believe it also does a comparison of a raw Rack request versus a non-cake PHP page.
I won't try to handwave away its faults.
Neither than I -- only pointing out that most people aren't even doing benchmarks. It's just accepted that "Ruby is Slow". I'm not saying it's fast, but I am saying that when you say things like this:
We're talking order of magnitude here, not marginal stuff that only shows up in benchmarking.
It might be nice to have some simple examples and numbers to back that up -- besides just factorial. They'd also be great to establish this point:
For what I do, that's OK, because the ten minutes to run the job is completely dwarfed by the development time saved by using a sane language.
If you're comparing a ten-line Ruby script with a hundred-line Perl script, and the Perl script is ten times faster, that would pretty clearly show the advantages of each language.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 3, Insightful
Hardware is only cheap if someone else is paying for it.
No, hardware is cheap, relative to programmer time. Moore's Law only reinforces this. In fact, you're making my argument for me:
Why spend money you don't have to?
Let's suppose it takes me half the time to code it in Rails than it does to code it in PHP, but requires twice the power to run. And let's suppose I make minimum wage.
Before it even comes close to costing more to run the hardware than it does to run my salary, you're already running six or seven extra-large instances. Go look up the specs for an extra-large instance. And keep in mind, that's additional -- that assumes the optimized version requires six or seven of those, and my inefficient version requires six or seven more.
You can run the numbers yourself, but it ultimately tends to work out the same. And all of that assumes the Ruby version is slower -- and, following my link above, it really isn't.
Smaller organizations won't save millions, but they'll save a significant chunk of cash.
Smaller organizations, I would think the "just throw hardware at it" argument makes even more sense. The speed of a nonworking app is irrelevant. The speed of an app serving a dozen programmers and testers, before public release, is similarly irrelevant. By the time you're getting hundreds or thousands of requests per second, you're probably making enough money from ads alone to cover the costs -- but while you're still "only" getting dozens of requests per second, a single Rails server might work just fine.
Now, I agree, throwing hardware at it is not a good long-term solution. The good long-term solution is to optimize the better systems. However, investing in a demonstrably worse architecture to gain a little performance -- maybe -- in the short term, does not seem like a good move.
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 2, Interesting
You do realize neither Ruby nor Rails is an acronym, right? Ok.
The only argument for it in the past for web dev is RAILs and there are plenty of MVC frameworks for PHP now including PHPulse, Cake and Codeigniter.
Hardware is cheap. Couldn't you throw more at the problem?
Re:I am afraid, there is lack of direction for Rub
on
Ruby 1.9.1 Released
·
· Score: 1
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
If you see no advantages to using it over PHP, you obviously haven't looked very hard.
Off the top of my head: Ruby has better syntax, a better object model, runs faster (really), better standard libraries -- Rails aside, Ruby tends not to pollute the global namespace with bullshit like mysql_escape_magic_quotes_no_really_I_mean_it_this_time...
PHP's advantage? Lots of unimaginative programmers like you know it, and it's slightly better at mixing code and data, since it's really just a Turing-complete template language. But I like haml anyway, and regardless, the template is one tiny part of your app -- the actual application logic should be buried in the model somewhere.
So for the majority of the program, PHP has no advantage. For the tiny minority where it would, in a well-designed app, haml makes it look so ugly it's not even funny.
And it's not just the effect, it's how fucking stupid this bug is, and that no one caught it. The bug is that each character you type into the search causes a separate background thread to be launched. This works OK, so long as your hard drive is indexed -- each thread will quickly access the index, and then return. If it's not, your system is going to be unusable for a few hours, or days, or until you forceably reboot.
Think about this. You type "hello" into the search field. You now have five separate threads, each doing a fulltext search of your hard drive.
One for h. One for he. One for hel. One for hell. One for hello.
Each one attempting to read every byte of your hard drive, individually, looking for those words.
I would be embarrassed to work at a company that put out shit like that.
It also supports large amounts of RAM, and virtual memory, all transparently. With DOS, you need hacks borrowed from Windows to support more than 64 megs of RAM, and you need to do manual tricks to get more than 640 kilobytes.
I could go on... but really, isn't multitasking enough there?
- Can XP do the same composition in the UI as Vista?
Do I care? No, I really don't. It's eye candy, and it makes Vista require absurdly more hardware than it should.
- Can XP encrypt the hole disk ?
Can Vista, without third-party support? I know XP can, if you have that support.
- Has XP Mandatory Access Control as Vista?
If you mean UAC, I'm really not looking forward to that. Only Microsoft could fuck up Sudo...
As for transactionally modifying the registry, good job, you're now on par with every other database since the 80s, good job. Filesystem, sounds cool, but is there any reason that should require more resources?
And yes, this is all relevant. XP provides far more than DOS does, and it actually needs hardware for that. The only case where that's true for Vista is the composition, and as Compiz shows, Vista's compositing is much, much slower than it needs to be.
His demonstrated usage of paragraphs is relevant to the discussion at hand in what way?
In exactly the same way as his ad-hominim about me knowing nothing about software development.
There is no such thing as bug free software.
You know, that's the second time I've heard that tonight...
It's possible to build provably correct software. It's possible to build a mathematical proof to verify the integrity of said software. And while it's still likely that there might be a lingering bug in said proof, it's not impossible for there to be no bugs at all.
The reason you never see this is that such software is both difficult and costly -- much more costly than what you're describing, the "good enough" software, or software which is very close to bug-free.
You don't seem to know much about Linux deployment. These days you install from USB.
No, these days I install the OS from a disk image, over the network. Then I install software from package managers -- the software which isn't baked into the image. Then I install my custom apps, currently via a system like Capistrano.
At one point, I had installation images distributed over a netboot GRUB menu, usually loaded via PXE. For machines which didn't have functioning network cards, I walked around with a floppy. For machines without floppy drives, I stuck said floppy on a CD via El-Torito.
However, for a typical desktop CD, or a physical server, a CD is still the simplest, if only because it's still the easiest way to be sure I've got something that will boot anywhere and still be useful.
Perhaps I should have worded it differently -- the most you've lost is a ten cent blank CD.
You might have a good point, but I have sufficient doubt that I won't take it on faith without numbers to back it up. Either I'm too lazy, or I can't find that information. Either provide sufficient evidence to convince me, or we'll have to agree to disagree.
I think "citation needed" is a lot more succinct than all of that, and I think it's useful to know which of our ideas are based in actual fact, and which are merely speculation we've repeated until we believe it's fact.
You don't seem to know much about software development.
Alright, then. Despite working as a software developer for years, clearly I'm inferior to someone who doesn't even know how to use paragraphs.
There is no such thing as bug free software.
Wrong. It's just prohibitively expensive to produce it, in cases more complex than "Hello, World."
The question is whether or not those bugs are show stoppers...meaning they break something critical to the functionality of the product.
Also whether they are known.
I realize it's different in the commercial world, because with a few notable exceptions (Google), you can't sell beta or release candidate software -- you have to pretend it's a final release. However, in the open source world, aside from KDE, people have no problem leaving it pre-release -- by release candidate status, most software is easily desktop-ready, and once released, production server ready.
And you don't read very well. I did not say "no bugs remaining", I said "no known bugs remaining."
Is it the perfect product?... The myth of Linux being somehow above reproach is just that: a myth.
Strawmen. I never claim Linux was beyond reproach, or that I expect Windows to be perfect.
However, when there's a new Linux kernel released, it's pretty much ready to go into production. When there's a new Ubuntu released, people pretty much just push the Upgrade button. When there's a new Windows released, everyone waits for SP1 before even considering rolling it to production, or to corporate desktops.
What makes that really inexcusable is, Microsoft charges for that first release. With Ubuntu, if it doesn't work out, you've lost a ten cent blank CD.
I could make a tweaked command line version of windows thatd be super fast.... Itd just be uglier.
Well, actually, no you couldn't. Windows requires a video card, and a GUI. The best you could do is run a commandline window fullscreen, as your shell.
More modular. Think WoW. The gui and various things are modular so different versions can be made.
Look at Linux. Pick any window manager you want. Build one from scratch. Mix and match a window manager and a desktop environment.
WinFS, or a filesystem that operates by tags rather than simple folders
WinFS would be entirely the wrong approach. I agree with your goal, but I think WinFS was a stupid way to do that.
Multiple desktops please!
Ah... so when you say you've been disappointed by OSes, you mean Microsoft OSes?
MACROs... basically a more flexible commandline allowing for scripts to be dropped straight into the commandline.
Not really sure where you're going with this. Macros as in, tracking mouse movements and replaying them? Sounds fragile.
Slashdot Mirror
It's like the rest of the OS -- it works for some things, not for others.
However, occasionally, what you need and what Wine/Linux provides sync up perfectly. Then, there are a lot of good reasons to switch -- free-as-in-beer being the obvious one.
As an example: I have tried plenty of programs in Wine, and watched them fail horribly. Others, I simply don't want to sacrifice a dozen FPS and some visual quality to play Portal on Linux, when I can just keep an XP partition around.
But every now and then, you end up with something like Filemaker or Quicken working just perfectly -- and if the only remaining app a user depends on is in that list, they can pretty much stop booting Windows.
Even if Wine never "catches up", every user who can use Wine instead of Windows is a win. And those users who do make the switch aren't likely to switch back because of a new app that isn't supported -- they're more likely to try to get it supported, or seek out another app.
So, even in a perfect world, where Linux achieves at least some 20 or 30% marketshare, to where people can no longer ignore it (and possibly starting a tidal wave of Windows users jumping ship), Wine probably wouldn't be perfect. But it would be enough to drive demand, and change the game.
How many developers want to put in the extra effort for a 0.1% wider audience?
Developers who find actual numbers, instead of pulling them out of their ass.
And that means doing a little market research. The market for your app may be biased one way or the other. For instance, if you're selling a text editor targeted at programmers -- or better yet, an SCM -- it's probably not too difficult to port, and you'll probably get quite a few grateful Linux users.
consider the Linux crowd has the "free (as in beer) software mentality"....
Can we get past this already? It seems the only Linux folk who have that mentality are complete strawmen created by people who've never actually met a Linux user.
I actually bought Windows XP, despite Linux being my primary OS. Most Windows users I know will pirate it if it didn't come with the machine.
There is one exception to that rule: On Windows, there are tons of little freeware (but closed source) utilities like IrfanView, WinRAR, etc. On Windows, and to a larger extent, OS X, there's even more -- a massive culture of shareware, where tiny cataloging utilities and file management utilities are selling for $10 to $20 each.
So, if your app is something truly useful, sure. I would love to see things like Photoshop support Wine officially (I'll use Gimp when I can, but it still hasn't caught up), and I love that WoW releases Wine-specific patches, and Eve uses Winelib.
But if you're trying to sell me a $15 version of diff or merge, it had better iron my socks, too.
The problem is, over the years, I start to find that my original naming scheme no longer appeals to me, so when I get a new box, it usually ends up with a different name.
The first with a proper name was a desktop: Morpheus (after the Matrix character). Next was a laptop: Trinity.
Then I got sick of The Matrix, so when I bought two desktops, one to use as a headless server (fileserver, mailserver, etc), I used Halo names: Grunt (server) and Elite (desktop).
I got a Mac, and decided it should have a wholly different name -- Eve, after the Applegeeks robot.
And now I have a shiny new Dell laptop running Ubuntu, named Serenity, after everyone's favorite Firefly-class transport.
Plus a Slicehost slice named Kernel...
I've worked at places that had consistent naming schemes, and those were worse -- one was based on metallurgy, so servers had names like Cobalt, Chromium, Molybdenum, etc. Cobalt was fine, Chromium was fine, but to type (and remember!) Molybdenum was pushing it. As confusing as my own naming scheme is, at least they're all relatively easy words.
one with a lot more options that batchfiles lol.
Batchfiles are Turing-complete, I'm fairly sure. And anything you can't do from there means the program itself likely hasn't exposed that functionality via the commandline.
Linux shell scripts are getting there but still not as nice... Sending commands directly to applications would be the big change.
I can do that. It's called dbus. Among other things, I can execute Javascript within any Konqueror window, I can pause/play Amarok, and I can pull passwords out of kwallet.
'winamp.stop', 'mplayer.openfile('C:MyMovies')' are examples.
Yep. I can do that.
I think the whole batch file system windows has should be replaced by a new system.
Like PowerShell?
Atm to get teh script i wrote above to work i'd have to get plugins for winamp and wmp ... and since one doesnt exist for wmp i'd have to code that.
Or use something other than windows media player.
Either way batchfiles are NOT for the regular user, I bet half of my second year CS class has never used one.
I think that says more about your CS class than it does about batchfiles. I don't know a single programmer who doesn't at least use a few.
You could start one program, close it, then start another and still have a standard UI between them.
Which is still not a standard GUI to manage them, and a GUI is a big deal.
Windows didn't get true multitasking till NT, before that programs were pretty much put on hold till they were focused on again.
And yet, as a user, I wouldn't care nearly as much about boring details like that -- multicore wasn't at all common, then.
Seriously, given the choice between running exactly one application at a time, and having to type a command to open it, then close it and switch to another...
Versus being able to simply leave several programs open, and switch between them with alt+tab?
True or not, multitasking is a huge deal, as much so as the GUI aspect. I'd rather run any version of Windows than DOS, unless I can cheat by running loadlin.exe or win.exe.
if usage grows much faster than the complexity of the application, you eventually have to address the problem with programmers rather than hardware, especially if your business model doesn't involve profits growing linearly with usage.
However, there should be some amount of profit which improves linearly -- why wouldn't you throw some Google ads on the site?
As for usage growing faster than complexity, we generally call this "A nice problem to have."
Now I'm not saying that our case is the norm...far from it.
And I'll concede that there are many situations outside the norm, which is why I would love to see Ruby get faster. I see nothing in the syntax and behavior of either language to suspect that Java should automatically be faster than Ruby.
But for now, there's still embedded systems, mainframes, operating system kernels, console video games, and many, many other places where a language like Ruby isn't even remotely appropriate.
I will make one more argument: Every greenfield app should probably at least be prototyped in something like Ruby. If you find yourself in a situation like you've described, you can always rewrite in another language. But since it's a greenfield app, what you want to avoid is letting a competitor get their version out the door before yours, even if your version is more efficient than theirs.
I'm curious whether you considered JRuby?
The idiom of "let's throw more hardware at the problem" is a way of saying "we don't know jack shit about how to build a scalable web application,
You're misusing the word "scalable". You probably mean vertical scalability, or performance.
And it's not saying we don't know how to build a performant application. It's saying we don't care, because programmer time is more expensive than CPU time. It's simply not worth it to optimize past a certain point.
you're looking for a miracle since it's a known fact RoR doesn't scale very well.
Citation needed.
Also, you are again talking about vertical scalability. Rails is actually excellent at horizontal scalability, which means, specifically, "Can we throw more servers at it and have it just work?"
Not every PHP app can do that. Nor every Python, or Java app. However, unless you do something stupid, every Rails app can be scaled by throwing hardware at it.
Keep in mind, you will have to do this at some point. No Amazon, or Myspace, or Google, is going to run off a single server, no matter how massive. They all have to scale horizontally. You have to address that problem sooner or later.
So, I'm arguing that horizontal scalability is more important than vertical scalability. Horizontal scalability means you can ultimately handle as much traffic as you can find hardware for. Vertical scalability means you save some money on hardware -- that's all.
just following the RoR hype of it being the best thing since sliced bread, which it's not.
No, it's not, but it's still pretty damned good.
Hype does not automatically make something a bad idea. Does anyone remember the hype about AJAX? I think most Rails hype is tame compared to that, but as it turned out, AJAX is pretty useful. It's not the Best Thing Ever, but it's still useful.
If you can find where I've said Rails is the best thing ever, please, point it out. Otherwise, please try to reply to just my post, not every Rails developer ever.
Why would I as a business be expected to switch to a language that requires twice as much hardware?
Because it requires half as many programmers, and hardware is far cheaper than programmers.
What you MAY save with software dev speed, you now lose with day to day server maintenance.
Server maintenance? Ah, I see, you're well behind the times.
See, I can fire up another Amazon EC2 instance with a single command, or automatically from a script. And since I assemble and manage them with scripts, once I get it past a single instance, it takes exactly as much effort to manage twenty as it does to manage two.
And your comment about "moving parts" is equally dated, if you're thinking in terms of likelihood for a CPU to fail. Once I've got two, if either fails, the other can notice and fire up a new instance, killing that one. Failing hardware then becomes Amazon's problem, not mine.
And seriously, day to day maintenance? Haven't touched the 3mix server in over a week. If you have to perform manual maintenance on a production server every day, you're Doing It Wrong.
The key to good engineering is to simplify because the more parts, the more chance of failure.
This is true of code, also. Fewer lines of code means fewer moving parts. Ruby commonly means fewer lines of code.
when similar languages such as PHP, PERL and PYTHON can do it with far less hardware is not a very good solution.
Can they, though? Follow the link in the post you're replying to. Ruby is not significantly slower than PHP in real-world benchmarks -- in a few of them, it's significantly faster.
So basically you're pissed that your hobby language (and make no mistake, that's all Ruby will ever be)
Some hobbies are quite profitable.
there are more "unimaginative programmers" who know it thus allowing business to move forward with doing actual in an attempt to make a profit.
That is why I tend to move towards small businesses and startups. You don't need those "more programmers" -- you need the five or ten programmers it will take to get the job done. More than that is just people warming seats.
But then, PHP makes it so easy to botch the job the first time, you can pretty much guarantee there will be more programmers back to warm seats.
And no, I'm not really pissed about it. Actually, I'm happy about it. See, I know PHP, so I can use it if I have to. I also know Ruby, and there are fewer people who know Ruby. That makes me valuable -- and it makes the one startup out of twenty that's using Ruby instead of PHP that much more likely to succeed.
You'll always a cog in the machine.
I've never been a cog in the machine, not in my working adult life.
You don't understand business, that much is obvious.
I'm not paid to. I'm paid to write good code, which I can do more effectively and more productively in Ruby than in PHP.
Except that slideshow is comparing the performance of popular frameworks for different languages.
I believe it also does a comparison of a raw Rack request versus a non-cake PHP page.
I won't try to handwave away its faults.
Neither than I -- only pointing out that most people aren't even doing benchmarks. It's just accepted that "Ruby is Slow". I'm not saying it's fast, but I am saying that when you say things like this:
We're talking order of magnitude here, not marginal stuff that only shows up in benchmarking.
It might be nice to have some simple examples and numbers to back that up -- besides just factorial. They'd also be great to establish this point:
For what I do, that's OK, because the ten minutes to run the job is completely dwarfed by the development time saved by using a sane language.
If you're comparing a ten-line Ruby script with a hundred-line Perl script, and the Perl script is ten times faster, that would pretty clearly show the advantages of each language.
Hardware is only cheap if someone else is paying for it.
No, hardware is cheap, relative to programmer time. Moore's Law only reinforces this. In fact, you're making my argument for me:
Why spend money you don't have to?
Let's suppose it takes me half the time to code it in Rails than it does to code it in PHP, but requires twice the power to run. And let's suppose I make minimum wage.
Before it even comes close to costing more to run the hardware than it does to run my salary, you're already running six or seven extra-large instances. Go look up the specs for an extra-large instance. And keep in mind, that's additional -- that assumes the optimized version requires six or seven of those, and my inefficient version requires six or seven more.
You can run the numbers yourself, but it ultimately tends to work out the same. And all of that assumes the Ruby version is slower -- and, following my link above, it really isn't.
Smaller organizations won't save millions, but they'll save a significant chunk of cash.
Smaller organizations, I would think the "just throw hardware at it" argument makes even more sense. The speed of a nonworking app is irrelevant. The speed of an app serving a dozen programmers and testers, before public release, is similarly irrelevant. By the time you're getting hundreds or thousands of requests per second, you're probably making enough money from ads alone to cover the costs -- but while you're still "only" getting dozens of requests per second, a single Rails server might work just fine.
Now, I agree, throwing hardware at it is not a good long-term solution. The good long-term solution is to optimize the better systems. However, investing in a demonstrably worse architecture to gain a little performance -- maybe -- in the short term, does not seem like a good move.
You do realize neither Ruby nor Rails is an acronym, right? Ok.
The only argument for it in the past for web dev is RAILs and there are plenty of MVC frameworks for PHP now including PHPulse, Cake and Codeigniter.
And those don't compare well, even to Rails, certainly not to Merb.
And Merb is going to be merged into Rails.
under large loads, it buckled
Hardware is cheap. Couldn't you throw more at the problem?
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
If you see no advantages to using it over PHP, you obviously haven't looked very hard.
Off the top of my head: Ruby has better syntax, a better object model, runs faster (really), better standard libraries -- Rails aside, Ruby tends not to pollute the global namespace with bullshit like mysql_escape_magic_quotes_no_really_I_mean_it_this_time...
PHP's advantage? Lots of unimaginative programmers like you know it, and it's slightly better at mixing code and data, since it's really just a Turing-complete template language. But I like haml anyway, and regardless, the template is one tiny part of your app -- the actual application logic should be buried in the model somewhere.
So for the majority of the program, PHP has no advantage. For the tiny minority where it would, in a well-designed app, haml makes it look so ugly it's not even funny.
You know, you have a point. I think all dynamic languages could probably learn something from the recent Javascript speed-up projects...
Except Ruby isn't slow.
And yes, I am happy about it being twice as fast, because it was already fast enough.
How about searches crashing the machine?
And it's not just the effect, it's how fucking stupid this bug is, and that no one caught it. The bug is that each character you type into the search causes a separate background thread to be launched. This works OK, so long as your hard drive is indexed -- each thread will quickly access the index, and then return. If it's not, your system is going to be unusable for a few hours, or days, or until you forceably reboot.
Think about this. You type "hello" into the search field. You now have five separate threads, each doing a fulltext search of your hard drive.
One for h.
One for he.
One for hel.
One for hell.
One for hello.
Each one attempting to read every byte of your hard drive, individually, looking for those words.
I would be embarrassed to work at a company that put out shit like that.
for developers, like DX 10 devs, I need a Vista machine.
But why would you be a DX10 dev, when most of your potential customers are avoiding Vista like the plague?
Or has something changed, recently?
A standard GUI, shared between apps.
Oops, that requires multitasking. Does it count?
It also supports large amounts of RAM, and virtual memory, all transparently. With DOS, you need hacks borrowed from Windows to support more than 64 megs of RAM, and you need to do manual tricks to get more than 640 kilobytes.
I could go on... but really, isn't multitasking enough there?
- Can XP do the same composition in the UI as Vista?
Do I care? No, I really don't. It's eye candy, and it makes Vista require absurdly more hardware than it should.
- Can XP encrypt the hole disk ?
Can Vista, without third-party support? I know XP can, if you have that support.
- Has XP Mandatory Access Control as Vista?
If you mean UAC, I'm really not looking forward to that. Only Microsoft could fuck up Sudo...
As for transactionally modifying the registry, good job, you're now on par with every other database since the 80s, good job. Filesystem, sounds cool, but is there any reason that should require more resources?
And yes, this is all relevant. XP provides far more than DOS does, and it actually needs hardware for that. The only case where that's true for Vista is the composition, and as Compiz shows, Vista's compositing is much, much slower than it needs to be.
I never learned much about winfs
Not a bad idea, but a bad implementation. Hans Reiser actually had a decent plan for this.
For macros i suppose i really mean scripts
Which we have, on Linux -- shell scripts. On Windows, you've got batchfiles, visual basic, etc...
What makes your idea different? Other than just wishing Windows had a better commandline?
His demonstrated usage of paragraphs is relevant to the discussion at hand in what way?
In exactly the same way as his ad-hominim about me knowing nothing about software development.
There is no such thing as bug free software.
You know, that's the second time I've heard that tonight...
It's possible to build provably correct software. It's possible to build a mathematical proof to verify the integrity of said software. And while it's still likely that there might be a lingering bug in said proof, it's not impossible for there to be no bugs at all.
The reason you never see this is that such software is both difficult and costly -- much more costly than what you're describing, the "good enough" software, or software which is very close to bug-free.
You don't seem to know much about Linux deployment. These days you install from USB.
No, these days I install the OS from a disk image, over the network. Then I install software from package managers -- the software which isn't baked into the image. Then I install my custom apps, currently via a system like Capistrano.
At one point, I had installation images distributed over a netboot GRUB menu, usually loaded via PXE. For machines which didn't have functioning network cards, I walked around with a floppy. For machines without floppy drives, I stuck said floppy on a CD via El-Torito.
However, for a typical desktop CD, or a physical server, a CD is still the simplest, if only because it's still the easiest way to be sure I've got something that will boot anywhere and still be useful.
Perhaps I should have worded it differently -- the most you've lost is a ten cent blank CD.
I tend to use it strictly literally. That is:
You might have a good point, but I have sufficient doubt that I won't take it on faith without numbers to back it up. Either I'm too lazy, or I can't find that information. Either provide sufficient evidence to convince me, or we'll have to agree to disagree.
I think "citation needed" is a lot more succinct than all of that, and I think it's useful to know which of our ideas are based in actual fact, and which are merely speculation we've repeated until we believe it's fact.
You don't seem to know much about software development.
Alright, then. Despite working as a software developer for years, clearly I'm inferior to someone who doesn't even know how to use paragraphs.
There is no such thing as bug free software.
Wrong. It's just prohibitively expensive to produce it, in cases more complex than "Hello, World."
The question is whether or not those bugs are show stoppers...meaning they break something critical to the functionality of the product.
Also whether they are known.
I realize it's different in the commercial world, because with a few notable exceptions (Google), you can't sell beta or release candidate software -- you have to pretend it's a final release. However, in the open source world, aside from KDE, people have no problem leaving it pre-release -- by release candidate status, most software is easily desktop-ready, and once released, production server ready.
And you don't read very well. I did not say "no bugs remaining", I said "no known bugs remaining."
Is it the perfect product?... The myth of Linux being somehow above reproach is just that: a myth.
Strawmen. I never claim Linux was beyond reproach, or that I expect Windows to be perfect.
However, when there's a new Linux kernel released, it's pretty much ready to go into production. When there's a new Ubuntu released, people pretty much just push the Upgrade button. When there's a new Windows released, everyone waits for SP1 before even considering rolling it to production, or to corporate desktops.
What makes that really inexcusable is, Microsoft charges for that first release. With Ubuntu, if it doesn't work out, you've lost a ten cent blank CD.
Once MS stops patching holes in WinXP, you either have to move on, or run everything in a sandbox.
I'm not GP, but it's probably going to take a lot more work from Microsoft before "run it in a sandbox" is less appealing than "upgrade to Vista SP3."
I could make a tweaked command line version of windows thatd be super fast.... Itd just be uglier.
Well, actually, no you couldn't. Windows requires a video card, and a GUI. The best you could do is run a commandline window fullscreen, as your shell.
More modular. Think WoW. The gui and various things are modular so different versions can be made.
Look at Linux. Pick any window manager you want. Build one from scratch. Mix and match a window manager and a desktop environment.
WinFS, or a filesystem that operates by tags rather than simple folders
WinFS would be entirely the wrong approach. I agree with your goal, but I think WinFS was a stupid way to do that.
Multiple desktops please!
Ah... so when you say you've been disappointed by OSes, you mean Microsoft OSes?
MACROs... basically a more flexible commandline allowing for scripts to be dropped straight into the commandline.
Not really sure where you're going with this. Macros as in, tracking mouse movements and replaying them? Sounds fragile.