"And that is the problem with Linux. What non-nerd user wants to do or even would know how to do this sort of thing?"
And this is the problem with old outdated comments (referring to the grandparent). They spread misinformation and give Linux a bad name. The information posted by BlueParrot is completely out of date.
In Ubuntu 7.10 (Gibbon), there's no need for this anymore. Thanks to BulletProof X, if X fails to start because of a video driver issue, the user will be redirected to a graphical configuration tool running in VESA mode. The user can then use that graphical configuration tool to select the correct video driver, and X will work fine again.
People, it's not 1998 anymore. Check out what's possible in the latest version!
I thought you might have a point until you said "Heck even Ubuntu (currently the distro that most nearly meets these requirements) has at least three variations.".
Just what is wrong with having 3 variations of Ubuntu? They're all Ubuntu, i.e. they're binary compatible with each other. If you make an Ubuntu package, that package will work on Kubuntu and Xubuntu as well. The package manager will install any dependencies you might need. The differences between the Ubuntu editions are smaller than differences between Vista Home, Vista Professional, Vista Ultimate and whatever the other 3 Vista editions are called. Just like a.exe will work on different Vista editions, a.deb will work fine on different Ubuntu editions.
Now, I'm not arguing that that.deb may not work on other Linux distros, but I really don't understand why you're complaining about Ubuntu havving different editions. I really don't see the problem.
I don't want to. This morning I left my laptop at home, powered on to download a torrent. I want to turn off the monitor to save power, but there is no on-off button for the monitor. So I closed the lid, and the monitor powered off.
In this situation, I wouldn't want it to automatically suspend. In fact, I read a few Slashdot posts in which the authors say that they find it extremely annoying that their MacBook do suspend automatically, preventing them to close their lid temporarily to drink a cup of coffee without breaking Internet connections.
Worked fine for me. Although it didn't suspend when I close the laptop lid (I don't know whether it's supposed to; this is my first laptop), the Suspend button on the logout dialog worked fine. Resuming also worked fine. No apps crashed or freaked out. Internet connection restored as it is supposed to.
My new Dell laptop (Inspiron 6400) arrived just today. The perfect chance to install the latest Ubuntu.
I'm very impressed. Wireless networking worked out-of-the-box. Battery support works out-of-the-box (if I remove the power cable, Ubuntu will switch to power saving mode just like Vista would; battery meter is shown by default). I can plug and unplug USB mouses at will. Partitioning the system is painless because it supports non-destructive NTFS resizing out-of-the-box. I have absolutely no idea why so many people are complaining about Linux laptop support.
Windows doesn't even support forking. You can start new processes, but forking the existing process is impossible. Even things like Cygwin only emulate it with threads.
I'm an Autopackage developer, and you and jimcus hit right on the nail. It is exactly as you said.
Arguing on Slashdot/OSNews/mailing lists proved to be useless though. Most people are just spectators who flame you for you opinion once in a while. Even if you convinced them, they aren't the kind of people who can do anything about the situation anyway. You'd have to convince the distributors instead. Most right now the mentally is still that different Linux distros are different operating systems and therefore don't have a reason to be compatible.
"This misses the point. Thanks to the clean integration with Apache and reasonable performance, PHP doesn't need threading support to scale. Scaling Ruby web apps without resorting to threading at some point or other on the other hand is a lot harder in part because people are prepared to go to great lengths to avoid the startup overhead with Ruby."
If that wasn't your point, then I didn't understand (and actually still don't understand) your point. Ruby on Rails's startup overhead is large, yes. But I don't see why this means they must use threads. Typical Ruby on Rails setup these days are as follows: 1. Run 10 (or any arbitrary number of) Mongrel instances. 2. Setup Apache mod_proxy_balancer to proxy HTTP requests to one of the Mongrel instances, as load balancer. (1) will allow you to fully utilize concurrency and your multicore CPU.
To scale this application, simply increase the number of Mongrel instances. Those instances may run on another computer. If the HTTP load balancer can't handle it, buy more load balancer servers and setup DNS load balancing to balance the load balancers, or upgrade the load balancer server.
This isn't any different from PHP is it? To scale PHP, buy more web servers and install the PHP app on them (and setup your load balancer). To scale Rails, buy more web servers and install the Rails app on them (and setup your load balancer).
Did you know PHP is similar to Rails with regard to using processes? The PHP documentation explicitly discourages people to use the threading backend in Apache, and encourage them to use the MPM backend instead, which creates child processes. Apache creates x child processes, each process processing one request at the same time. The main Apache process proxies requests to one of the child processes. This is architecturally very similar to Apache mod_proxy_balancer plus a pack of Mongrels.
"I agree, to a point. But going multi-process instead of multi-threading suddenly increases the communication overhead significantly, and it's extra work."
In theory, yes. But how significant is it in practice? If there's one thing I've learned from all those years I've spent on programming, then it's that performance issues are rarely at places where you expect them to be. Some stupid little thing that you've never thought about may consist 30% of the application's CPU usage, while the part that you spent a week trying to optimize turned out to be insignificant after all. My experience with web applications is that the time taken to send data through the communication channel is negligible compared to everything else (that is, the time taken to actually request the process). In Ruby on Rails, building the final output HTML seems to take a significant amount of time. I can't imagine that the time taken to send a few kilobytes over a Unix socket (or even a TCP socket) back to the load balancer, is significant compared to that.
"Also, the cost of going multi-process with Ruby is significant because of the gc - you WILL triger copy on write for a large set of your data very easily. Proper threading would have made that far less of an issue."
I do agree that the Ruby interpreter can and should be better than it is right now. But I don't think using multiple threads will make things any easier on the garbage collector. The current Ruby interpreter uses a simple mark-and-sweep algorithm, and its execution time is linear (proportional to the number of objects). If you put multiple threads in the Rails app then the heap will become larger, and GC will take more time than when you only have one thread.
Still waiting for them to implement generational garbage collection...
"Completely incorrect. Of course Python does have the GIL which means they're only good for blocking on I/O and not actual parallel computation. And neither Jython nor IronPython have the GIL."
Well the guys at #python told me that Python uses green/userspace threads.
It's good that Jython/IronPython don't have a GIL but are they production-ready? They're kinda useless for most existing Python apps until they can run those apps perfectly fine. Last time I checked, someone said that they don't implement the entire CPython standard library.
"Perl also has threading support (and no GIL) and no, it does not copy the entire interpreter state, and hasn't done so since perl 5.6 at least."
Really? Then can you explain why: - My 78000 lines Perl program takes 15 seconds to create a thread? On top of that, it crashes right after thread creation. - Every single documentation on the Internet about Perl threads seem to suggest that they're heavyweight. I quote: "Perl ithreads are not lightweight!" - The official Perl threading documentation says that variables are, by default, not shared between threads unless you explicitly mark them as shared.
"The threading model in Ruby, for example, is completely fucked up and kills performance if you need to do many threads and a lot of IO at the same time." As opposed to PHP which doesn't have threads at all?
I really don't understand the obsession with threads. Why not just use processes? Running multiple processes allows you to fully utilize that dual core CPU of yours. Plus it doesn't involve messing with locks and conditional variables, an important source of bugs. If one process crashes, the others are unaffected. And finally, if an app uses 5 MB RAM and you run 10 instances of that app, then that doesn't equal 50 MB memory usage. Modern operating systems do their best to share memory between processes, and support copy-on-write memory handling. If your 250 MB process forks, then the child process only uses a few KB memory and not another 250 MB.
In fact, Perl and Python have similar/the same problems. Perl threads are heavyweight: each thread copies the entire interpreter memory state! This makes thread creation hideously slow (a moderate-sized Perl app can take 15 seconds to create a thread), unstable (threads are still considered experimental) and memory consuming. Python threads are, like Ruby threads, user-space threads and not kernel threads. When I think about it, I don't even know one scripting language which has proper kernel threads support. Your "Rails fanboys" comment is completely pointless.
I already replied to a message like this before but I will do it again:
Give me one good reason why I SHOULD write that "very quick PHP" function. In Rails, I don't have to. Nor do I think I should have to. And writing "very quick PHP functions" 90 times for 30 different tables and 3 different applications quickly become tiresome. As I said: boilerplate code.
"This may be because you are doing store-and-retrieve only, for which I agree SQL is overkill. However many people with databases need to do complex relational algebra which becomes very clunky when you are using a programming language and not a dedicated relational algebra declarative language such as SQL."
That is true, but in most web applications most database actions are of the "store and retrieve records" type. For everything else, Rails doesn't prevent you from writing SQL. Indeed, most of my websites have some SQL-based finder methods in the models, usually for querying aggregate information. I've never had to write SQL manually when saving stuff though.
"Expressing transactions is also difficult - the abstraction becomes 'leaky'." Not with Rails though:
BankAccount.transaction do
account1 = BankAccount.find_by_name('Joe')
account2 = BankAccount.find_by_name('Jane')
account1.amount -= 100
account2.amount += 100
account1.save!
account2.save!
BankAccount.transaction do ...more database actions here, for nested transactions...
end end
If an exception is thrown within the toplevel 'do' block, then the entire transaction is aborted with a 'ROLLBACK'.
"#1 - "IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN'T DO?... (thinking)... NO."" I might as well ask the opposite: is there anything PHP can do that Rails can't? Nope. PHP doesn't give me any reason to switch back from Rails. This entire argument doesn't mean anything.
"#3 - DON'T WANT WHAT I DON'T NEED" It's the "not invented here" syndrome. "I didn't write it, so I don't want it, I want to use everything I wrote myself." A pretty weak argument. I don't know the entire Rails core either. Nor do I have to. I use what I need, and that's it. Everything in Rails that I don't need, doesn't get in my way.
"#4 - IT'S SMALL AND FAST" This statement is pretty meaningless without providing website statistics. How many visitors does he have per day?
"#6 - I LOVE SQL" This is purely a personal thing. I like SQL for complex queries, but for simple CRUD operations on records, why should I have to type the same boilerplate code over and over and over and over again? It's much simpler to type
user = User.new user.name = params[:name] user.save
than to type
$db->execute(sprintf("INSERT INTO users VALUES(NULL, %s)", $db->quote($_GET['user'])))
The former is easier to read and easier to write.
"#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER" I really don't understand what he's trying to argue here.
#2 is actually a valid point, but this isn't really Rail's fault. I can't argue to #5 as that's purely subjective.
So? If you don't like Tomboy then don't enable it. Until recently I didn't even know Tomboy uses Mono. The fact that I didn't increase any significant increases in memory usage just proves that it's good enough.]
Furthermore, "takes as much memory as the rest of core Gnome together" is bollocks. In the System Monitor, Tomboy uses 24.5 MB resident memory, of which 14.7 MB is shared memory and only 9.8 MB is writable (private) memory.
Are you sure? Torrents usually need some time to get to decent speed. Will torrents speed up quickly enough, *and* have enough peers to provide the data in the preferred order in time? I somehow doubt that, most of the videos I download (except the extremely, extremely popular ones with 30000 seeds) are not finished downloading in less time than the video length.
Uhm, what are you talking about? How do you want to run a new, yet-to-be-developed P2P protocol in a current version of Opera without installing software?
Oh and I forgot to ask this as well: how do you get around firewalls/NAT? Most people these days are behind NAT. In my experience, UPnP only works out-of-the-box on very few systems because most routers have UPnP disabled by default.
Slashdot Mirror
It's automatic, and only available in Ubuntu 7.10. If it didn't work for you, you should submit a bug report.
"And that is the problem with Linux. What non-nerd user wants to do or even would know how to do this sort of thing?"
And this is the problem with old outdated comments (referring to the grandparent). They spread misinformation and give Linux a bad name. The information posted by BlueParrot is completely out of date.
In Ubuntu 7.10 (Gibbon), there's no need for this anymore. Thanks to BulletProof X, if X fails to start because of a video driver issue, the user will be redirected to a graphical configuration tool running in VESA mode. The user can then use that graphical configuration tool to select the correct video driver, and X will work fine again.
People, it's not 1998 anymore. Check out what's possible in the latest version!
Why? Vista adaption is held back by many things, but the existence of different editions doesn't seem to be one of them.
I thought you might have a point until you said "Heck even Ubuntu (currently the distro that most nearly meets these requirements) has at least three variations.".
.exe will work on different Vista editions, a .deb will work fine on different Ubuntu editions.
.deb may not work on other Linux distros, but I really don't understand why you're complaining about Ubuntu havving different editions. I really don't see the problem.
Just what is wrong with having 3 variations of Ubuntu? They're all Ubuntu, i.e. they're binary compatible with each other. If you make an Ubuntu package, that package will work on Kubuntu and Xubuntu as well. The package manager will install any dependencies you might need. The differences between the Ubuntu editions are smaller than differences between Vista Home, Vista Professional, Vista Ultimate and whatever the other 3 Vista editions are called. Just like a
Now, I'm not arguing that that
I don't want to. This morning I left my laptop at home, powered on to download a torrent. I want to turn off the monitor to save power, but there is no on-off button for the monitor. So I closed the lid, and the monitor powered off.
In this situation, I wouldn't want it to automatically suspend. In fact, I read a few Slashdot posts in which the authors say that they find it extremely annoying that their MacBook do suspend automatically, preventing them to close their lid temporarily to drink a cup of coffee without breaking Internet connections.
Worked fine for me. Although it didn't suspend when I close the laptop lid (I don't know whether it's supposed to; this is my first laptop), the Suspend button on the logout dialog worked fine. Resuming also worked fine. No apps crashed or freaked out. Internet connection restored as it is supposed to.
My new Dell laptop (Inspiron 6400) arrived just today. The perfect chance to install the latest Ubuntu.
I'm very impressed. Wireless networking worked out-of-the-box. Battery support works out-of-the-box (if I remove the power cable, Ubuntu will switch to power saving mode just like Vista would; battery meter is shown by default). I can plug and unplug USB mouses at will. Partitioning the system is painless because it supports non-destructive NTFS resizing out-of-the-box. I have absolutely no idea why so many people are complaining about Linux laptop support.
By that reasoning, proprietary licenses are the best since they restrict developer freedom (specifically, the author's freedom) the least.
Freedom comes at a price. Granting freedom to a party means restricting a different party.
Windows doesn't even support forking. You can start new processes, but forking the existing process is impossible. Even things like Cygwin only emulate it with threads.
I'm an Autopackage developer, and you and jimcus hit right on the nail. It is exactly as you said.
Arguing on Slashdot/OSNews/mailing lists proved to be useless though. Most people are just spectators who flame you for you opinion once in a while. Even if you convinced them, they aren't the kind of people who can do anything about the situation anyway. You'd have to convince the distributors instead. Most right now the mentally is still that different Linux distros are different operating systems and therefore don't have a reason to be compatible.
Really? Then go for it! That's a HUGE improvement compared to the current 95% male 5% female!!!1111
"This misses the point. Thanks to the clean integration with Apache and reasonable performance, PHP doesn't need threading support to scale. Scaling Ruby web apps without resorting to threading at some point or other on the other hand is a lot harder in part because people are prepared to go to great lengths to avoid the startup overhead with Ruby."
If that wasn't your point, then I didn't understand (and actually still don't understand) your point. Ruby on Rails's startup overhead is large, yes. But I don't see why this means they must use threads. Typical Ruby on Rails setup these days are as follows:
1. Run 10 (or any arbitrary number of) Mongrel instances.
2. Setup Apache mod_proxy_balancer to proxy HTTP requests to one of the Mongrel instances, as load balancer.
(1) will allow you to fully utilize concurrency and your multicore CPU.
To scale this application, simply increase the number of Mongrel instances. Those instances may run on another computer. If the HTTP load balancer can't handle it, buy more load balancer servers and setup DNS load balancing to balance the load balancers, or upgrade the load balancer server.
This isn't any different from PHP is it? To scale PHP, buy more web servers and install the PHP app on them (and setup your load balancer). To scale Rails, buy more web servers and install the Rails app on them (and setup your load balancer).
Did you know PHP is similar to Rails with regard to using processes? The PHP documentation explicitly discourages people to use the threading backend in Apache, and encourage them to use the MPM backend instead, which creates child processes. Apache creates x child processes, each process processing one request at the same time. The main Apache process proxies requests to one of the child processes. This is architecturally very similar to Apache mod_proxy_balancer plus a pack of Mongrels.
"I agree, to a point. But going multi-process instead of multi-threading suddenly increases the communication overhead significantly, and it's extra work."
In theory, yes. But how significant is it in practice? If there's one thing I've learned from all those years I've spent on programming, then it's that performance issues are rarely at places where you expect them to be. Some stupid little thing that you've never thought about may consist 30% of the application's CPU usage, while the part that you spent a week trying to optimize turned out to be insignificant after all.
My experience with web applications is that the time taken to send data through the communication channel is negligible compared to everything else (that is, the time taken to actually request the process). In Ruby on Rails, building the final output HTML seems to take a significant amount of time. I can't imagine that the time taken to send a few kilobytes over a Unix socket (or even a TCP socket) back to the load balancer, is significant compared to that.
"Also, the cost of going multi-process with Ruby is significant because of the gc - you WILL triger copy on write for a large set of your data very easily. Proper threading would have made that far less of an issue."
I do agree that the Ruby interpreter can and should be better than it is right now. But I don't think using multiple threads will make things any easier on the garbage collector. The current Ruby interpreter uses a simple mark-and-sweep algorithm, and its execution time is linear (proportional to the number of objects). If you put multiple threads in the Rails app then the heap will become larger, and GC will take more time than when you only have one thread.
Still waiting for them to implement generational garbage collection...
"Completely incorrect. Of course Python does have the GIL which means they're only good for blocking on I/O and not actual parallel computation. And neither Jython nor IronPython have the GIL."
Well the guys at #python told me that Python uses green/userspace threads.
It's good that Jython/IronPython don't have a GIL but are they production-ready? They're kinda useless for most existing Python apps until they can run those apps perfectly fine. Last time I checked, someone said that they don't implement the entire CPython standard library.
"Perl also has threading support (and no GIL) and no, it does not copy the entire interpreter state, and hasn't done so since perl 5.6 at least."
Really? Then can you explain why:
- My 78000 lines Perl program takes 15 seconds to create a thread? On top of that, it crashes right after thread creation.
- Every single documentation on the Internet about Perl threads seem to suggest that they're heavyweight. I quote: "Perl ithreads are not lightweight!"
- The official Perl threading documentation says that variables are, by default, not shared between threads unless you explicitly mark them as shared.
"The threading model in Ruby, for example, is completely fucked up and kills performance if you need to do many threads and a lot of IO at the same time."
As opposed to PHP which doesn't have threads at all?
I really don't understand the obsession with threads. Why not just use processes? Running multiple processes allows you to fully utilize that dual core CPU of yours. Plus it doesn't involve messing with locks and conditional variables, an important source of bugs. If one process crashes, the others are unaffected. And finally, if an app uses 5 MB RAM and you run 10 instances of that app, then that doesn't equal 50 MB memory usage. Modern operating systems do their best to share memory between processes, and support copy-on-write memory handling. If your 250 MB process forks, then the child process only uses a few KB memory and not another 250 MB.
In fact, Perl and Python have similar/the same problems. Perl threads are heavyweight: each thread copies the entire interpreter memory state! This makes thread creation hideously slow (a moderate-sized Perl app can take 15 seconds to create a thread), unstable (threads are still considered experimental) and memory consuming. Python threads are, like Ruby threads, user-space threads and not kernel threads.
When I think about it, I don't even know one scripting language which has proper kernel threads support. Your "Rails fanboys" comment is completely pointless.
I already replied to a message like this before but I will do it again:
Give me one good reason why I SHOULD write that "very quick PHP" function. In Rails, I don't have to. Nor do I think I should have to. And writing "very quick PHP functions" 90 times for 30 different tables and 3 different applications quickly become tiresome. As I said: boilerplate code.
That is true, but in most web applications most database actions are of the "store and retrieve records" type. For everything else, Rails doesn't prevent you from writing SQL. Indeed, most of my websites have some SQL-based finder methods in the models, usually for querying aggregate information. I've never had to write SQL manually when saving stuff though.
"Expressing transactions is also difficult - the abstraction becomes 'leaky'."
Not with Rails though: If an exception is thrown within the toplevel 'do' block, then the entire transaction is aborted with a 'ROLLBACK'.
Yes I have. But those functions and classes *are* the boilerplate code. Why should I have to write them manually?
"#1 - "IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN'T DO?
I might as well ask the opposite: is there anything PHP can do that Rails can't? Nope. PHP doesn't give me any reason to switch back from Rails. This entire argument doesn't mean anything.
"#3 - DON'T WANT WHAT I DON'T NEED"
It's the "not invented here" syndrome. "I didn't write it, so I don't want it, I want to use everything I wrote myself." A pretty weak argument.
I don't know the entire Rails core either. Nor do I have to. I use what I need, and that's it. Everything in Rails that I don't need, doesn't get in my way.
"#4 - IT'S SMALL AND FAST"
This statement is pretty meaningless without providing website statistics. How many visitors does he have per day?
"#6 - I LOVE SQL"
This is purely a personal thing. I like SQL for complex queries, but for simple CRUD operations on records, why should I have to type the same boilerplate code over and over and over and over again? It's much simpler to type than to type The former is easier to read and easier to write.
"#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER"
I really don't understand what he's trying to argue here.
#2 is actually a valid point, but this isn't really Rail's fault. I can't argue to #5 as that's purely subjective.
So? If you don't like Tomboy then don't enable it. Until recently I didn't even know Tomboy uses Mono. The fact that I didn't increase any significant increases in memory usage just proves that it's good enough.]
Furthermore, "takes as much memory as the rest of core Gnome together" is bollocks. In the System Monitor, Tomboy uses 24.5 MB resident memory, of which 14.7 MB is shared memory and only 9.8 MB is writable (private) memory.
Yet the alternative is over population. Choose your poison.
You are not wrong. The Free Software Foundation explicitly states that binaries produced by GCC are not covered by the GPL. (Why people never read the GPL FAQ is beyond me.)
I can only think of two reason why they want to replace GCC with PCC:
1. Because they can.
2. Because they're anti-GPL zealots.
Are you sure? Torrents usually need some time to get to decent speed. Will torrents speed up quickly enough, *and* have enough peers to provide the data in the preferred order in time? I somehow doubt that, most of the videos I download (except the extremely, extremely popular ones with 30000 seeds) are not finished downloading in less time than the video length.
But can Bittorrent be used for streaming media? I don't think so.
Uhm, what are you talking about? How do you want to run a new, yet-to-be-developed P2P protocol in a current version of Opera without installing software?
Oh and I forgot to ask this as well: how do you get around firewalls/NAT? Most people these days are behind NAT. In my experience, UPnP only works out-of-the-box on very few systems because most routers have UPnP disabled by default.