My exposure to ext4 is so far limited to running it on a VM running Ubuntu 9.04 since a few months prior to its April, '09 release. I've noticed improved disk I/O performance, and have experienced no data loss. I'm considering running it on some non-critical production systems, but that's beside my point, which I didn't make clear, so I'll try to do so now:
Before doing something as extreme as running a newly released filesystem on a not-yet-released distro, I read the distro's release notes to know what the issues and risks were. After doing this with Ubuntu 9.04 beta, I was expecting the possibility of data loss with ext4, so took appropriate steps (set up regular backups, etc.) As a distro test pilot, I packed a parachute (backups), and expected to use it.
Making a statement today (post- Ted's fix, which has been applied to the Ubuntu 9.04 Linux kernel) such as "I lost data for the first time while running ext4 on Ubuntu (pre-fix)" is unfair and misleading. The question being posed is "is ext4 stable for production systems (implied: "now", and assuming: "in a released Linux distro")?", not "was it stable for production systems a few months ago, in a beta distro release?".
If people are only concerned with a single technical issue, and that issue has been resolved with a fix from the project maintainer, then we need to be asking questions more like, "Was this the right fix?", then: "Has ext4 been properly vetted, and is therefore trustworthy enough for production systems?", and "If not yet, then when?".
A couple of months ago i installed Ubuntu 9.01, which used ext4 by default. Running it, i experienced data loss for the first time since i moved from ext2 to ext3 quite a few years ago now. I've just changed back to ext3 - which has been rock solid for me since it first appeared in Redhat or whatever distro it was i was using back then.
There's no such thing as Ubuntu 9.01. I'm assuming you mean Ubuntu 9.04 (aka. "Jaunty"). If you installed that a few months ago, you installed it while it was still in pre-release status. It also uses ext3 by default, not ext4. See http://www.ubuntu.com/testing/jaunty/beta#Ext4%20filesystem%20support . where the Ubuntu team says "Ubuntu 9.04 Beta supports the option of installing the new ext4 file system. ext3 will remain the default filesystem for Jaunty, and we will consider ext4 as the default for the next release based on user feedback. There has been extensive discussion about the reliability of applications running on ext4 in the face of sudden system outages. Applications that use the conventional approach of writing data to a temporary file and renaming it to its final location will have their reliability expectations met in Ubuntu 9.04 beta; further discussion is ongoing in the kernel community."
Er...if BPL is up in said emergency, and ham fails, then why not just use the BPL connection?
What if BPL isn't up? You've lost your entire communications system when the power goes out.
Since radios work on generators, or even batteries, they're great communications tools for emergency situations.
Phone company sales rep: "We have this new technology that makes the phone system work, even when the power's out." Customer: "Isn't that just POTS?" Sales rep: "Not any more. Now it's Emergency Phone Services, and we charge more for it."
Like everything else in Ubuntu, I had no problem configuring printers in CUPS. This is mainly because the web interface tells you to use gnome-cups-manager, and even tells you where it is in the system's menu structure. Really user friendly.
Re:One of the advantages of Linux
on
Linux Cookbook
·
· Score: 2, Informative
No, that's not true of NT. In NT, you need to login to the graphical environment before you can get to the command line (unless you're running in non-graphical Safe Mode). In Linux, I can ctrl-alt-F1 out of GDM or a running X session, directly to the command line. There are times that this is desirable.
There's also some good battlemap software out there that allows a DM/GM to put together really detailed maps very quickly. Check out Dundjinni, for example: http://www.dundjinni.com/
I'm using it to put together really detailed battlemaps in like 15-20 minutes prep time.
I can't agree more, and have seen this approach work incredibly well in corporate environments. It also works at home. I run my home Windows PC (XP Pro, SP2) with limited user privs, switching to the Administrator user only when I specifically have to apply patches, install new software or change file permissions. In other words, I operate in Windows the way I would under Linux, using 'runas' in place of 'su'.
It is possible through Active Directory policy settings to restrict files from being able to execute on Windows PCs within a domain. You can define these "do not run" programs by several means such as file path or even hash rules. This way, even if you're required (by company policy, or whatever) to give users administrative access to their PCs, you can still keep spyware-infected PCs on your domain from running installed spyware code.
That said, does anyone maintain a public list of install paths and/or hashes for known spyware/malware? I realize that Ad-Aware, Spybot S&D, etc. need to maintain this info internally, but does anyone provide it in an easy-to-import-to-policy format? Even one big, fat text file, or a spreadsheet would be handy.
flatplanet.net Shut Down (aka Re:What?)
on
Gnutella Vs. SPAM
·
· Score: 5
For those of you wondering what happened to http://www.flatplanet.net, they have been shut down. The timing of this article on/. could not have been timed better, as www.flatplanet.net was scheduled for disconnect today due to complaints against the software they sell, which was found to be against DSL.net's AUP and TOS.
Like any true spam promoter on the Internet, alas, they will most likely move their operations and continue with their unethical practices.:P
Slashdot Mirror
Check out the BUG open source hardware/software platform. It would let you do something like this.
http://buglabs.net/
My exposure to ext4 is so far limited to running it on a VM running Ubuntu 9.04 since a few months prior to its April, '09 release. I've noticed improved disk I/O performance, and have experienced no data loss. I'm considering running it on some non-critical production systems, but that's beside my point, which I didn't make clear, so I'll try to do so now:
Before doing something as extreme as running a newly released filesystem on a not-yet-released distro, I read the distro's release notes to know what the issues and risks were. After doing this with Ubuntu 9.04 beta, I was expecting the possibility of data loss with ext4, so took appropriate steps (set up regular backups, etc.) As a distro test pilot, I packed a parachute (backups), and expected to use it.
Making a statement today (post- Ted's fix, which has been applied to the Ubuntu 9.04 Linux kernel) such as "I lost data for the first time while running ext4 on Ubuntu (pre-fix)" is unfair and misleading. The question being posed is "is ext4 stable for production systems (implied: "now", and assuming: "in a released Linux distro")?", not "was it stable for production systems a few months ago, in a beta distro release?".
If people are only concerned with a single technical issue, and that issue has been resolved with a fix from the project maintainer, then we need to be asking questions more like, "Was this the right fix?", then: "Has ext4 been properly vetted, and is therefore trustworthy enough for production systems?", and "If not yet, then when?".
A couple of months ago i installed Ubuntu 9.01, which used ext4 by default. Running it, i experienced data loss for the first time since i moved from ext2 to ext3 quite a few years ago now. I've just changed back to ext3 - which has been rock solid for me since it first appeared in Redhat or whatever distro it was i was using back then.
There's no such thing as Ubuntu 9.01. I'm assuming you mean Ubuntu 9.04 (aka. "Jaunty"). If you installed that a few months ago, you installed it while it was still in pre-release status. It also uses ext3 by default, not ext4. See http://www.ubuntu.com/testing/jaunty/beta#Ext4%20filesystem%20support . where the Ubuntu team says "Ubuntu 9.04 Beta supports the option of installing the new ext4 file system. ext3 will remain the default filesystem for Jaunty, and we will consider ext4 as the default for the next release based on user feedback. There has been extensive discussion about the reliability of applications running on ext4 in the face of sudden system outages. Applications that use the conventional approach of writing data to a temporary file and renaming it to its final location will have their reliability expectations met in Ubuntu 9.04 beta; further discussion is ongoing in the kernel community."
Yeah, but they're running it as root.
Er...if BPL is up in said emergency, and ham fails, then why not just use the BPL connection?
What if BPL isn't up? You've lost your entire communications system when the power goes out.
Since radios work on generators, or even batteries, they're great communications tools for emergency situations.
Phone company sales rep: "We have this new technology that makes the phone system work, even when the power's out."
Customer: "Isn't that just POTS?"
Sales rep: "Not any more. Now it's Emergency Phone Services, and we charge more for it."
Like everything else in Ubuntu, I had no problem configuring printers in CUPS. This is mainly because the web interface tells you to use gnome-cups-manager, and even tells you where it is in the system's menu structure. Really user friendly.
No, that's not true of NT. In NT, you need to login to the graphical environment before you can get to the command line (unless you're running in non-graphical Safe Mode). In Linux, I can ctrl-alt-F1 out of GDM or a running X session, directly to the command line. There are times that this is desirable.
The do what the cavemen did while they were waiting for their flights - sit down and shut up.
Contrary to popular belief, you don't need to have a cellphone shoved into your ear, or a web browser in your face 24/7.
There's also some good battlemap software out there that allows a DM/GM to put together really detailed maps very quickly. Check out Dundjinni, for example: http://www.dundjinni.com/
I'm using it to put together really detailed battlemaps in like 15-20 minutes prep time.
Morons? Check again. They already hacked you, and put all of your stuff on their system.
I can't agree more, and have seen this approach work incredibly well in corporate environments. It also works at home. I run my home Windows PC (XP Pro, SP2) with limited user privs, switching to the Administrator user only when I specifically have to apply patches, install new software or change file permissions. In other words, I operate in Windows the way I would under Linux, using 'runas' in place of 'su'.
It is possible through Active Directory policy settings to restrict files from being able to execute on Windows PCs within a domain. You can define these "do not run" programs by several means such as file path or even hash rules. This way, even if you're required (by company policy, or whatever) to give users administrative access to their PCs, you can still keep spyware-infected PCs on your domain from running installed spyware code.
That said, does anyone maintain a public list of install paths and/or hashes for known spyware/malware? I realize that Ad-Aware, Spybot S&D, etc. need to maintain this info internally, but does anyone provide it in an easy-to-import-to-policy format? Even one big, fat text file, or a spreadsheet would be handy.
Shibby.
Like any true spam promoter on the Internet, alas, they will most likely move their operations and continue with their unethical practices. :P
Thanks for reading, and not spamming,
Al Gordon
Sr. UNIX Systems Administrator
DSL.net, Inc.
http://www.dsl.net/