but if there's a problem, then linux makes win3.1 dll hell look like a paradise. even linux experts feel massively frustrated and helpless in that situation.
As a self proclaimed Linux Expert, I'm really not sure what you're getting at.
In my usage, 98% of the time when I want a package it's in the package repositiory of the distro I'm using, installs without a hitch, and works perfectly.
The remaining 2% breaks down like this:
Installs from source. This works the same on Windows, so there's no difference here. The class of Windows users who don't need to know about this don't need to know about it on Linux either. Hell, it's easier on Linux - if you disagree go build a source package from CVS on Windows. Firefox, OpenOffice, Gimp, and Gaim are examples of packaged heavily used on Windows with source packages and CVS archives available.
Installs from broken packages. This has never happened to me on a stable distribution, and the package has been fixed in the repository within 24 hours on unstable distros every time. No Windows junky would be terribly suprized if they had trouble installing something random... say Lotus Notes... on the new Longhorn beta - it's not a stable release.
Pretty simply, the package + repository system is way cleaner than anything Windows has, and any claims of "nightmare dependancy situations" are probably the result of users intentionally doing things the hard way rather than using offical packages from their distributor.
It's like if a Windows user copied a friend's "C:\Program Files\Front Page" directory to their computer and complained it didn't work rather than using an installer - possible, but I'm sure as hell not going to give you any sympathy if you don't get it to work.
The more I think about the specific problem that's being solved here (speeding up a "Find" tool), the more I agree with you that from a software development standpont a 20 meg user-specific memory resident daemon is ludicrous. This is a task for 20 lines of Perl and a nightly cron job.
On the other hand, I still stand by the point I was trying to make to begin with: Heavy runtime environments like Java and Mono work well, and the couple megs of RAM that you pay by using programs written in these frameworks are usually a very good deal. Twenty megs of RAM per user for functionality that relevently and positively impacts productivity is an amazing bargain.
Normally, a webserver has a public IP and needs to be able to accept and respond to incoming HTTP requests on port 80 from any internet address.
Additionally, people need to be able to manage the server - a simple UNIX setup would give the entire internet access to SSH on port 23.
A more paranoid UNIX setup would restrict SSH access to a specific range of IP addresses through the SSH configuration. (Note that it doesn't matter if the allowed IP range is "inside the firewall" or not.)
In eithor case, a firewall would never block a connection that the host would have accepted. A firewall is good redundancy.
I didn't mean that the linux machine will get more sales, I meant that the linux machine will get a reasonable number of sales - significatly more than the 3% or so implied by current market share.
I really don't think that most computer buyers look for "Windows" as a feature of a new computer - most people don't care. A machine with higher specs for less money should be a good draw.
I don't understand this obsession with open ports. The firewall is a kludge to make up for insecure services that you haven't managed to turn off on machines behind it - if there are no insecure services running, there's no security issue.
Now, I'm not going to argue that you shouldn't have firewalls, because they protect against random idiots turning on services that should be turned off as well as against some OS network stack vulnerabilities, but I can *assure* you that if a competent JR System administrator has decided to open port 16773 on the firewall for some random specific service he'll be running, it's a hell of a lot smaller a security risk than having outgoing port 80 open.
First, I wouldn't blame Mono for the problem. Having a little application level memory bloat in a version 0.11 application seems reasonable. I'm sure they'll get around to memory optimization when it's the right time.
On the other hand, 20 megs really isn't that much RAM. If this application had any notable value to your users, it would be nearly free to provide that RAM for the application, even with 20 users.
I mean, by your benchmarking system 7 megs of RAM is normal for a freshly started text editor. If search functionality is really important, I don't see "uses the RAM of three text editor instances" as terribly bad.
nat@icewing:~$ free total used free Mem: 1036316 795084 241232 nat@icewing:~$ gedit & nat@icewing:~$ free total used free Mem: 1036316 801980 234336 nat@icewing:~$ emacs & nat@icewing:~$ free total used free Mem: 1036316 808164 228152
Although I wouldn't consider changing a working network architecture for a program like Beagle, your worry about RAM / CPU time may indicate that A.) your setup has scaling issues or B.) you haven't properly investigated the scaling problem.
In an optimal shared-server environment using commodity hardware and your own floor space, RAM and CPU time are pretty damn cheap. Like, if this program wants to use its own CPU and 512 megs of RAM 24/7, that should be a good deal if it will save 16 man-hours of time.
The slowest core you're going to get in a desktop or laptop today is a 550 mhz low power VIA processor with 128 megs of SDR RAM - and you'd need to try *really hard* to find it. From what I hear, the VIA processors are about the same as origional AMD Athlons clock for clock. Todays Gnome desktops could use some optimization for that class of system to run smoothly.
On the other hand, those processors are already obsolete, and the replacement is in the distribution pipeline. The next generation stuff from VIA is 800 mhz minimum and supports DDR RAM - about the same as my slowest test system. Current versions of Gnome should run fine on that as-is.
So... optimization for smooth performance is useful on: Rare low power systems that are already obsolete, and common desktops from five years ago.
By the time an optimization cycle starting now were to finish, no new system will be slow enough to need it.
I think that
Gnumeric would be a perfect fit for this situation. It performs a useful function, and it's open source software that runs on Linux.
Oh, wait. No. If I suggested that I'd be doing what you did - posting completely random and off topic suggestions because of distant similarities with the topic at hand.
I tend to think that if the following machines were next to eachother at CompUSA, the Linux one would get a good chunk of sales compared to the windows one:
$349 - AMD Sempron 3000+ 2GHz Processor, 256MB RAM, 80GB Hard Drive, 16X DVD / 48X32X48 CD-RW Combo Drive, Windows XP Home Edition
$339 - AMD Sempron 3000+ 2GHz Processor, 512MB RAM, 80GB Hard Drive, 16X DVD / 48X32X48 CD-RW Combo Drive, Linux OS, 1 Year 24/7 Phone Support
There are exactly two advantages Windows has over Linux on the desktop:
- It's preinstalled on most computers.
- It runs more video games.
The second one is entirely dependant on market share, and is only the driving factor in a small percentage of OS purchase decisions (I'd guess that less than 10% of computers are bought with the intention of playing commercial video games.)
If Linux came pre-installed on computers, few inexperienced users would notice the difference. In fact, they'd probably have an easier time because OpenOffice is preinstalled and there's no viruses.
Therefore, Windows will lose as soon as cheap Linux boxes equivilent to Dells are generally available.
$500 more is a good first guess, but I think you're shooting low. I'd suggest "More than twice as expensive" as a good starting point.
As a data point, I recently got a new laptop and built a new destop for my cousin. In both cases I took full advantage of the internet and got everything as cheaply and efficiently as possible.
For systems with the following specs:
~1.8 ghz gaming processor (Athlon 64 3000+ for the desktop, Pentium M 750 for the laptop);
1 gig of RAM;
80 gig hard drive;
PCI Express GeForce 6600;
Dual Layer DVD Writer;
Large, high resolution display (19" crt @ 1600x1200 & 15.4" LCD @ 1680x1050)
I paid about $1800 for the laptop and about $800 for the desktop. That's not taking into account a secondary battery and external mouse that I needed for the laptop, bringing the actual laptop price up another $150.
I tend to think that theres nothing wrong with/usr/bin/perl or/bin/bash or/etc/resolv.conf - these paths work so there's no reason to go out of our way to change them.
On the other hand, it'd be neat to have this label functionality for user files. Here's how to implement it very simply on top of, say, Linux/KDE:
Store all files in their owner's home directory directly, or with an "~/b/bu/bus/business-letter" structure.
Have a directory called "~/.labels". Put a file in it for each label that's a sorted list of the files with that label. Also have a file called "~/.labels/reverse-lookup" which maps filenames to labels.
Replace the file manager and standard file dialogs (Save As and Open) with versions that use labels instead of directories, with whatever GUI you want.
Leave the programming interface and command line as is.
What I've described gives you 90% of what you want, or 100% from the non-power-user perspective without requiring any radical restructuring of the core OS.
If you're actually going to change the file system that radically, you have a new operating system on your hands - therefore there's no reason to preserve the "cd" directory change syntax (especially since you don't have directories any more).
On the other hand, this type of concept could be implemented on top of an existing file system structure at the desktop environment / graphical file manager level.
So reinstalling Windows is like a cheat code from an old video game? I wouldn't exactly call that user friendly.
And once it's installed, you're not done. In order to get up to the standard of a fresh install of other desktop operating systems you still need to install a number of applications, hardware drivers, and get antivirus/antispyware/firewall software working.
Windows is easier to install than Linux in that with most new computers it's already installed.
Beyond that, I'd bet that in a fair comparison of ease of installation, most desktop targetted Linux distros would beat Windows hands down.
Ease of installation has never been a major design goal for Windows. It's been one of the top complaint points for Linux for 10 years - this resulted in some of the cleanest install processes I've ever encountered.
Slashdot Mirror
As a self proclaimed Linux Expert, I'm really not sure what you're getting at.
In my usage, 98% of the time when I want a package it's in the package repositiory of the distro I'm using, installs without a hitch, and works perfectly.
The remaining 2% breaks down like this:
Pretty simply, the package + repository system is way cleaner than anything Windows has, and any claims of "nightmare dependancy situations" are probably the result of users intentionally doing things the hard way rather than using offical packages from their distributor.
It's like if a Windows user copied a friend's "C:\Program Files\Front Page" directory to their computer and complained it didn't work rather than using an installer - possible, but I'm sure as hell not going to give you any sympathy if you don't get it to work.
Hmm... while actually building an index file, 20 megs is small potatoes given a sufficiently large set of files to search.
The more I think about the specific problem that's being solved here (speeding up a "Find" tool), the more I agree with you that from a software development standpont a 20 meg user-specific memory resident daemon is ludicrous. This is a task for 20 lines of Perl and a nightly cron job.
On the other hand, I still stand by the point I was trying to make to begin with: Heavy runtime environments like Java and Mono work well, and the couple megs of RAM that you pay by using programs written in these frameworks are usually a very good deal. Twenty megs of RAM per user for functionality that relevently and positively impacts productivity is an amazing bargain.
Normally, a webserver has a public IP and needs to be able to accept and respond to incoming HTTP requests on port 80 from any internet address.
Additionally, people need to be able to manage the server - a simple UNIX setup would give the entire internet access to SSH on port 23.
A more paranoid UNIX setup would restrict SSH access to a specific range of IP addresses through the SSH configuration. (Note that it doesn't matter if the allowed IP range is "inside the firewall" or not.)
In eithor case, a firewall would never block a connection that the host would have accepted. A firewall is good redundancy.
An interesting point to remember is this: The major Linux GUI toolkits work under Windows.
Have you considered Fat32?
I didn't mean that the linux machine will get more sales, I meant that the linux machine will get a reasonable number of sales - significatly more than the 3% or so implied by current market share.
I really don't think that most computer buyers look for "Windows" as a feature of a new computer - most people don't care. A machine with higher specs for less money should be a good draw.
I don't understand this obsession with open ports. The firewall is a kludge to make up for insecure services that you haven't managed to turn off on machines behind it - if there are no insecure services running, there's no security issue.
Now, I'm not going to argue that you shouldn't have firewalls, because they protect against random idiots turning on services that should be turned off as well as against some OS network stack vulnerabilities, but I can *assure* you that if a competent JR System administrator has decided to open port 16773 on the firewall for some random specific service he'll be running, it's a hell of a lot smaller a security risk than having outgoing port 80 open.
First, I wouldn't blame Mono for the problem. Having a little application level memory bloat in a version 0.11 application seems reasonable. I'm sure they'll get around to memory optimization when it's the right time.
On the other hand, 20 megs really isn't that much RAM. If this application had any notable value to your users, it would be nearly free to provide that RAM for the application, even with 20 users.
I mean, by your benchmarking system 7 megs of RAM is normal for a freshly started text editor. If search functionality is really important, I don't see "uses the RAM of three text editor instances" as terribly bad.
In an optimal shared-server environment using commodity hardware and your own floor space, RAM and CPU time are pretty damn cheap. Like, if this program wants to use its own CPU and 512 megs of RAM 24/7, that should be a good deal if it will save 16 man-hours of time.
On the other hand, those processors are already obsolete, and the replacement is in the distribution pipeline. The next generation stuff from VIA is 800 mhz minimum and supports DDR RAM - about the same as my slowest test system. Current versions of Gnome should run fine on that as-is.
So... optimization for smooth performance is useful on: Rare low power systems that are already obsolete, and common desktops from five years ago. By the time an optimization cycle starting now were to finish, no new system will be slow enough to need it.
Mac OS *is* Unix. In fact, it's even *more Unix* than Linux is.
Oh, wait. No. If I suggested that I'd be doing what you did - posting completely random and off topic suggestions because of distant similarities with the topic at hand.
Yea, if you're willing to abuse the word "owner" and "take".
Yea... a shareware package that runs on Mac OS and Windows is a good response to a request for open source software that runs on Linux.
There are exactly two advantages Windows has over Linux on the desktop:
- It's preinstalled on most computers.
- It runs more video games.
The second one is entirely dependant on market share, and is only the driving factor in a small percentage of OS purchase decisions (I'd guess that less than 10% of computers are bought with the intention of playing commercial video games.)
If Linux came pre-installed on computers, few inexperienced users would notice the difference. In fact, they'd probably have an easier time because OpenOffice is preinstalled and there's no viruses.
Therefore, Windows will lose as soon as cheap Linux boxes equivilent to Dells are generally available.
$500 more is a good first guess, but I think you're shooting low. I'd suggest "More than twice as expensive" as a good starting point.
As a data point, I recently got a new laptop and built a new destop for my cousin. In both cases I took full advantage of the internet and got everything as cheaply and efficiently as possible.
For systems with the following specs:
~1.8 ghz gaming processor (Athlon 64 3000+ for the desktop, Pentium M 750 for the laptop); 1 gig of RAM; 80 gig hard drive; PCI Express GeForce 6600; Dual Layer DVD Writer; Large, high resolution display (19" crt @ 1600x1200 & 15.4" LCD @ 1680x1050)
I paid about $1800 for the laptop and about $800 for the desktop. That's not taking into account a secondary battery and external mouse that I needed for the laptop, bringing the actual laptop price up another $150.
On the other hand, it'd be neat to have this label functionality for user files. Here's how to implement it very simply on top of, say, Linux/KDE:
What I've described gives you 90% of what you want, or 100% from the non-power-user perspective without requiring any radical restructuring of the core OS.
On the other hand, this type of concept could be implemented on top of an existing file system structure at the desktop environment / graphical file manager level.
I'll be worried about that the minute I see a 51% or better market share for Novel Linux. Until then...
Yea, as long as you have all the install CDs, and are ok with saying "minutes" when you mean "hundreds of minutes".
The default applications installed are Firefox, Evolution, OpenOffice, Gaim, Rythmbox, Totem and some "solitaire" style games.
The only shortcoming I see for random desktop use is the lack of support for Windows Media 9 video.
And once it's installed, you're not done. In order to get up to the standard of a fresh install of other desktop operating systems you still need to install a number of applications, hardware drivers, and get antivirus/antispyware/firewall software working.
Windows is easier to install than Linux in that with most new computers it's already installed. Beyond that, I'd bet that in a fair comparison of ease of installation, most desktop targetted Linux distros would beat Windows hands down. Ease of installation has never been a major design goal for Windows. It's been one of the top complaint points for Linux for 10 years - this resulted in some of the cleanest install processes I've ever encountered.