Even on easy, it seems that some scenarios are impossible (or nearly so) if you don't carry enough gold and veteran units over from the previous scenarios. After about 10 tries on a scenario I restarted the game from scratch to build enough money to beat that one scenario only to get stuck again a couple scenarios later. It's not all difficult. A few scenarios are just a dozen times harder than the others.
From the FAQ: a customer has to purchase a server license for every DPM server that is deployed and a Data Protection Management License (DPML) for every server they protect.
Now they have incentive to never upgrade the poor quality backup software already included in Windows. Admins will have to buy their backup software seperately or look elsewhere. Server operating systems are expected to come with _good_ backup software, so from a strictly technical sense Microsoft is being an ass.
I've already switched to samba and rsync. Microsoft's backup was outdated by at least a decade, and even failed to complete at random when I've used it for disk to disk backups. And Windows' mandatory file locking policy makes safe, reliable backups entirely impossible. An xcopy backup is even dangerous, because it temporarily locks files as it opens them for reading, potentially causing other server processes to fail if they attempt to write to the files.
A lot of people have been arguing that Linux is safe from viruses because users don't run as root unless they need to.
A virus, worm, or trojan would not need to run as root to be effective. You don't need root to save programs to my home directory and execute them, or to send email. You don't need root to read almost every file in the file system (on most default setups). You don't need root to listen on high ports.
The real reasons why Linux has fewer viruses:
Executable flag: If a file is saved to the disk, and the user somehow attempts to execute it, it'll fail to run unless the program that saved it explicitly marked it as executable. Most email viruses depend on Windows' lack of this feature.
Containment: Running as a limited user makes it a lot easier to contain and clean malware. Damage is mostly restricted to the user's home directory. Installed programs are generally unaffected. They can't install browser spyware. A malware infection won't get so bad that you have to reinstall the operating system.
User demographic: Most Linux users know better than to get infected by a virus, on any operating system. My Windows PC's have always been virus-free. Plus, most Linux users prefer open source, making it very hard to bundle spyware and adware.
Learning curve: On the other end of the spectrum, grandma will have a steep learning curve to figure out how to infect her Linux system with a virus if she ever gets one. Someone who has figured out the simple task of logging in as root, marking a file as executable, and running the file probably knows how to avoid malware, which is handy because such knowledge is likely to be a prerequisite to installing said malware. The easiest way to install software on Linux is from a trusted repository.
Malware writers: Taking into account all of the above, and the market share of Linux among computer illiterates, Linux is not the best target for malware. If they had to choose between 2% of Windows users, or 0.01% of 1/10th as many Linux users, they'd choose to target Windows users.
Exploits are published every week, and occasionally a Linux virus is written and released, but very few Linux users in the world have ever seen a Linux virus, or know someone who has. Who wants to write a virus that'll infect just a few hundred systems at most, or market adware and spyware installing software to a demographic that prefers open source?
Go a week without using a shell. Easier said than done.
I don't think I could manage that even on Windows. I use the Windows command prompt almost every day. The difference is that I can do more at the Linux command line. Everything is scriptable. In Windows, I'm simply out of luck from time to time.
I doubt there's a big difference. I prefer X.org over XFree86 because it includes a bug fix which prevents it from crashing my system. The main thing is that if a distibution still uses XFree86, it's probably an old XFree86 from before the fork, with some fixes backported from X.org.
Given the choice between blocking more spam and blocking fewer legitimate emails, I'd rather settle with blocking fewer legitimate emails. Most RBL maintainers see it the other around. They are full of themselves and are generally unhelpful when they mess up. One or two offenses and they'll block an entire subnet.
Blacklists are good for flagging potential spams, but you never want to blackhole something unless you're absolutely sure.
I back up my cd's to ogg at a high bitrate, usually VBR averaging about 256kbit. I do all my transcoding from those 256kbit masters. On occasion I need to fit them on a small mp3 player or pack a bunch onto an mp3 cd, in which case 128 is desirable. I can barely hear distortion at 128, and only with a few songs.
We just have a stack of 24 port gigabit switches. 4 ports on each switch is set up as a trunk to connect them together, effectively turning them into one giant, fast, very cheap gigabit switch. Looking at the Cisco diagram, this might be considered our distribution layer.
We normally have one port on the switches for each system, with the exception that in some locations we have smaller switches to allow them to share a line, so that we don't have to rewire the building. We also use some smaller switches as repeaters to parts of the building too far away to connect directly to the central switches. Those small switches outside of the server room, along with all our servers and systems, might be considered our access layer.
Then we have a tiny linksys router, intended for home use, connecting the entire building to the internet. I know, it sounds scary, and unprofessional, but it seems plenty capable of filling the bandwidth of a T1 and tracking as many simultaneous tcp connections as we use. We'll consider replacing it at the first sign of trouble. I guess this is our core layer.
I suppose that whatever you use at the top level to connect your systems to create a single network can be called your distribution layer. The switches may get cheaper over the years, but it's the same thing. If you just have a chain of 8 port switches running around the building, then your distribution layer is a bunch of 8 port switches.
However you design your distribution and access layers, your main goals should probably be to minimize line problems (mostly due to distance) and avoid bottlenecks. You seem concerned about price, so if you decide to use 100mbit switches to keep the price down, I recommend that get the kind that have gigabit uplinks and plug them into a gigabit switch, and plug your servers into the gigabit switch as well. Otherwise, your effective bandwidth will be 100mbit total rather than 100mbit per user.
I have a similar timesheet monstrosity. People punch in and out each day by tapping on their photos on a touch screen and entering their code in the keypad that pops up. It tracks locations, vacations, overtime, attendance, and lunch. It keeps dual logs, one permanent, the other editable by a manager. It can store custom forms linked by employee and date, where the manager only needs to write an html version of the form and upload it. It has a message board, with personal message support. Hours are verified daily by the managers, and re-verified by the employee every week. The reports save tab-delimited copies to the clipboard for easy importing into a spreadsheet. It has an built-in database editor that even handles relationships for easy navigation of child records. It has 18 tables. It supports online upgrades using database patch scripts and version tracking. Now for the monstrous part: It's written entirely in javascript and html, and uses an Access database.
I was asked to write it for internal use, with intent to eventually sell if it gets good enough, but after beta testing with other companies it became clear that supporting business software and making it work for everyone is not something we're prepared to do. We're not even a software company. We're a manufacturing plant.
# of clients can be misleading. If it's the number of daily users, it could mean as little as 10 requests/second in an 8 hour day. Just about anything can handle that kind of load. If it's the number of simultaneous connections, then with a gigabit connection you could only serve about half a packet a second to 250000 clients, and I know Java doesn't scale to 250000 simultaneous threads. If they're talking about a horizontal scaling, as in a cluster, then load comparisons becomes almost meaningless without specifying the hardware. Depending on the application, with 10x servers you can usually handle nearly 10x the users, no matter what language you're using.
Notice that Slashdot is written in Perl, with nearly all dynamic pages. According to the FAQ, which may or may not be up to date, they have 8 single processor 600mhz PIII web servers and 1 quad 550mhz xeon MySQL server.
I suspect that when RHEL has serious server related problems, they are more quick to fix it. Another reason is the update schedule. Once a production server works, there is no reason to upgrade the OS except for bug, security, and performance fixes, which is what you mostly get with RHEL. With Fedora, you'll be forced into frequent feature upgrades that may introduce new problems. Generally, Fedora is better for desktops, and RHEL/WBEL/CentOS is better for servers.
I had some weird packet loss problems when I tried Fedora Core 3 as a server. Got about 20kb/s over a gigabit network. The problem was specific to the ethernet card I was using, but when I switched to CentOS everything worked perfectly. It was CentOS-3, since 4 wasn't out yet, but all the other 2.4 kernel based distros I tried didn't support the ethernet card at all.
WhiteBoxLinux.org is run by John Morris, the WBEL maintainer, and WhiteBoxLinux.com is run by Donavan Nelson, who has recently gotten more involved with CentOS. I personally use CentOS, because people have said that it gets more frequent updates.
Slashdot Mirror
'.' matches any character except newline.
I expect that the main thing they'll do is just raise the prices on products that used to compete.
Even on easy, it seems that some scenarios are impossible (or nearly so) if you don't carry enough gold and veteran units over from the previous scenarios. After about 10 tries on a scenario I restarted the game from scratch to build enough money to beat that one scenario only to get stuck again a couple scenarios later. It's not all difficult. A few scenarios are just a dozen times harder than the others.
Wouldn't simple color correction work?
Too much red and blue in my opinion. Is it only the expensive movies that can afford white fluorescent lights?
Source code licenses are meant for licensing source code.
No one believes me though.
MSBACKUP actually worked? It could skip bad floppies? WTF!? No way! In my experience, the smallest of errors will make any Microsoft program blow up.
From the FAQ:
a customer has to purchase a server license for every DPM server that is deployed and a Data Protection Management License (DPML) for every server they protect.
Now they have incentive to never upgrade the poor quality backup software already included in Windows. Admins will have to buy their backup software seperately or look elsewhere. Server operating systems are expected to come with _good_ backup software, so from a strictly technical sense Microsoft is being an ass.
I've already switched to samba and rsync. Microsoft's backup was outdated by at least a decade, and even failed to complete at random when I've used it for disk to disk backups. And Windows' mandatory file locking policy makes safe, reliable backups entirely impossible. An xcopy backup is even dangerous, because it temporarily locks files as it opens them for reading, potentially causing other server processes to fail if they attempt to write to the files.
A lot of people have been arguing that Linux is safe from viruses because users don't run as root unless they need to.
A virus, worm, or trojan would not need to run as root to be effective. You don't need root to save programs to my home directory and execute them, or to send email. You don't need root to read almost every file in the file system (on most default setups). You don't need root to listen on high ports.
The real reasons why Linux has fewer viruses:
Executable flag:
If a file is saved to the disk, and the user somehow attempts to execute it, it'll fail to run unless the program that saved it explicitly marked it as executable. Most email viruses depend on Windows' lack of this feature.
Containment:
Running as a limited user makes it a lot easier to contain and clean malware. Damage is mostly restricted to the user's home directory. Installed programs are generally unaffected. They can't install browser spyware. A malware infection won't get so bad that you have to reinstall the operating system.
User demographic:
Most Linux users know better than to get infected by a virus, on any operating system. My Windows PC's have always been virus-free. Plus, most Linux users prefer open source, making it very hard to bundle spyware and adware.
Learning curve:
On the other end of the spectrum, grandma will have a steep learning curve to figure out how to infect her Linux system with a virus if she ever gets one. Someone who has figured out the simple task of logging in as root, marking a file as executable, and running the file probably knows how to avoid malware, which is handy because such knowledge is likely to be a prerequisite to installing said malware. The easiest way to install software on Linux is from a trusted repository.
Malware writers:
Taking into account all of the above, and the market share of Linux among computer illiterates, Linux is not the best target for malware. If they had to choose between 2% of Windows users, or 0.01% of 1/10th as many Linux users, they'd choose to target Windows users.
Exploits are published every week, and occasionally a Linux virus is written and released, but very few Linux users in the world have ever seen a Linux virus, or know someone who has. Who wants to write a virus that'll infect just a few hundred systems at most, or market adware and spyware installing software to a demographic that prefers open source?
What about dual-boot?
Go a week without using a shell. Easier said than done.
I don't think I could manage that even on Windows. I use the Windows command prompt almost every day. The difference is that I can do more at the Linux command line. Everything is scriptable. In Windows, I'm simply out of luck from time to time.
Certainly there is an amount that would change their mind.
Lets hope that Bill Gates is a really really really big Star Trek fan.
Forgive me. I was repeating what I read elsewhere. Being as young as I am, it didn't conflict with any of my past experience.
Samba was first released in 1992, before Windows had file sharing.
You might get close with Vector Linux or Peanut Linux.
I doubt there's a big difference. I prefer X.org over XFree86 because it includes a bug fix which prevents it from crashing my system. The main thing is that if a distibution still uses XFree86, it's probably an old XFree86 from before the fork, with some fixes backported from X.org.
oxyride
Given the choice between blocking more spam and blocking fewer legitimate emails, I'd rather settle with blocking fewer legitimate emails. Most RBL maintainers see it the other around. They are full of themselves and are generally unhelpful when they mess up. One or two offenses and they'll block an entire subnet.
Blacklists are good for flagging potential spams, but you never want to blackhole something unless you're absolutely sure.
I back up my cd's to ogg at a high bitrate, usually VBR averaging about 256kbit. I do all my transcoding from those 256kbit masters. On occasion I need to fit them on a small mp3 player or pack a bunch onto an mp3 cd, in which case 128 is desirable. I can barely hear distortion at 128, and only with a few songs.
We just have a stack of 24 port gigabit switches. 4 ports on each switch is set up as a trunk to connect them together, effectively turning them into one giant, fast, very cheap gigabit switch. Looking at the Cisco diagram, this might be considered our distribution layer.
We normally have one port on the switches for each system, with the exception that in some locations we have smaller switches to allow them to share a line, so that we don't have to rewire the building. We also use some smaller switches as repeaters to parts of the building too far away to connect directly to the central switches. Those small switches outside of the server room, along with all our servers and systems, might be considered our access layer.
Then we have a tiny linksys router, intended for home use, connecting the entire building to the internet. I know, it sounds scary, and unprofessional, but it seems plenty capable of filling the bandwidth of a T1 and tracking as many simultaneous tcp connections as we use. We'll consider replacing it at the first sign of trouble. I guess this is our core layer.
I suppose that whatever you use at the top level to connect your systems to create a single network can be called your distribution layer. The switches may get cheaper over the years, but it's the same thing. If you just have a chain of 8 port switches running around the building, then your distribution layer is a bunch of 8 port switches.
However you design your distribution and access layers, your main goals should probably be to minimize line problems (mostly due to distance) and avoid bottlenecks. You seem concerned about price, so if you decide to use 100mbit switches to keep the price down, I recommend that get the kind that have gigabit uplinks and plug them into a gigabit switch, and plug your servers into the gigabit switch as well. Otherwise, your effective bandwidth will be 100mbit total rather than 100mbit per user.
I have a similar timesheet monstrosity. People punch in and out each day by tapping on their photos on a touch screen and entering their code in the keypad that pops up. It tracks locations, vacations, overtime, attendance, and lunch. It keeps dual logs, one permanent, the other editable by a manager. It can store custom forms linked by employee and date, where the manager only needs to write an html version of the form and upload it. It has a message board, with personal message support. Hours are verified daily by the managers, and re-verified by the employee every week. The reports save tab-delimited copies to the clipboard for easy importing into a spreadsheet. It has an built-in database editor that even handles relationships for easy navigation of child records. It has 18 tables. It supports online upgrades using database patch scripts and version tracking. Now for the monstrous part: It's written entirely in javascript and html, and uses an Access database.
I was asked to write it for internal use, with intent to eventually sell if it gets good enough, but after beta testing with other companies it became clear that supporting business software and making it work for everyone is not something we're prepared to do. We're not even a software company. We're a manufacturing plant.
For $100, you can get 100 or more rolls of toilet paper, which ought to last a few years.
# of clients can be misleading. If it's the number of daily users, it could mean as little as 10 requests/second in an 8 hour day. Just about anything can handle that kind of load. If it's the number of simultaneous connections, then with a gigabit connection you could only serve about half a packet a second to 250000 clients, and I know Java doesn't scale to 250000 simultaneous threads. If they're talking about a horizontal scaling, as in a cluster, then load comparisons becomes almost meaningless without specifying the hardware. Depending on the application, with 10x servers you can usually handle nearly 10x the users, no matter what language you're using.
Notice that Slashdot is written in Perl, with nearly all dynamic pages. According to the FAQ, which may or may not be up to date, they have 8 single processor 600mhz PIII web servers and 1 quad 550mhz xeon MySQL server.
I suspect that when RHEL has serious server related problems, they are more quick to fix it. Another reason is the update schedule. Once a production server works, there is no reason to upgrade the OS except for bug, security, and performance fixes, which is what you mostly get with RHEL. With Fedora, you'll be forced into frequent feature upgrades that may introduce new problems. Generally, Fedora is better for desktops, and RHEL/WBEL/CentOS is better for servers.
I had some weird packet loss problems when I tried Fedora Core 3 as a server. Got about 20kb/s over a gigabit network. The problem was specific to the ethernet card I was using, but when I switched to CentOS everything worked perfectly. It was CentOS-3, since 4 wasn't out yet, but all the other 2.4 kernel based distros I tried didn't support the ethernet card at all.
WhiteBoxLinux.org is run by John Morris, the WBEL maintainer, and WhiteBoxLinux.com is run by Donavan Nelson, who has recently gotten more involved with CentOS. I personally use CentOS, because people have said that it gets more frequent updates.