I've been using Seafile since April and I am very, very pleased with it. It is one of the few self hosted options that supports client side encryption and manages to scale up to a reasonably large number of files. It fell down on me in the 100k file range, but I was able to get around that issue by breaking my data up into smaller libraries.
The client side encryption was slightly problematic in the 1.x releases. Back then, you had to type your encryption passphrase into the server to create a new library. As of 2.0 you can create new libraries in the client without your passphrase leaving your local machine. You still can't dig through your file revision history without giving the server your passphrase; hopefully that functionality will be integrated into the client in the future.
I took a quick look at SparkleShare, ownCloud, and BitTorrent Sync, but none of them were a good fit for me. BitTorrent Sync only encrypts your data while it is in flight, ownCloud only supports server side encryption, and you can't properly store Git repos under SparkleShare.
It is a very bright, and I think it looks quite amazing. It is especially amazing at its sub-$350 price point. I'm pretty jealous of it, but my laptop lacks the dual link DVI port required for driving one of these displays. I would really like to upgrade from my pair of 1080p monitors to a pair of these!
He wrote about his 27" 2560x1440 monitor on his blog.
In some states, an adult is legally required to provide ID to any cop who asks - it's actually illegal to walk down the street without a driver's license (or non-driver's ID). We seem to have little regard for the Constitution.
There is for example an unresolved bug in ubuntu 8.10 which has bit me severly. It relates to total failure of sleep/hibernate and all that wonderful functionality on pci-e boxes.
Are you saying that all my laptops with pci-e video chipsets should be failing to suspend? Suspend and hibernate have worked fine on all my laptops for many years with Ubuntu, 8.10 or otherwise.
And no I won't provide the link to the bug, find it yourself on launchpad [launchpad.net] (I believe that is the correct access point)
It might be worth looking for the bug if you are more specific about the problem since there certainly isn't a suspend problem with every pci-e equipped machine.
And while uptimes are great, I often need to shut my box down so as to avoid cooking the occupants of my small apartment because it gets so bloody hot in here (26-27+`Celcius) in the middle of a Canadian winter with the heating set at 22.
The only thing that I dislike after resuming from a suspend is waiting for the damned wifi to connect. Resume takes 2-3 seconds or less. Reconnecting sometimes seems to take forever, especially in busy apartment complexes with 20+ aps in range.
Careful with that - some nuances will turn up that will bite you on the ass. I found out last year that Apache's MD5 module creates different hashes(!) on Windows than it does on UNIX.
If that is true then at least one of them isn't actually generating an MD5 hash.
I'm just guessing, but I bet you were also encoding the line ending characters. That would be encoded differently on Windows and UNIX, so you'd actually be hashing two strings that differed by at least one byte.
I don't check in things that I don't think are stable. I do that primarily through test-driven development and pair programming, plus automated acceptance testing and showing new versions to product management and/or QA every few hours.
Where do you keep things that you don't think are stable? Are you expecting that code to become stable at some point? If the code is eventually meant to go into production then your RCS is probably a good place to keep it while you're working on it.
I can only imagine that branching+merging is more difficult with your RCS than checking out a fresh copy. Either that, or you rarely have to check in a bug fix while you're in the middle of a "2-3 week" change.
Bugs only get harder to find over time. It seems a lot cheaper to me to kill them dead as soon as possible, rather than storing them up and trying to find them later.
I know that's not reasonable for every situation, but about 90% of the time I see people doing lots of branching and merging, it's a response to screwed-up organizations or dysfunctional personal relationships.
I constantly branch and merge even when I am the only one working on a codebase. When branching and merging are so easy why wouldn't you take advantage of it? Of course, it is always possible that I have a dysfunctional relation with myself.
That's not to say git isn't awesome for certain situations, mind you.
I can't speak for how awesome git is, I've never used it.
But branching and merging adds a fair bit of overhead, and anything that increases a project's overhead should be your last resort, not your first.
If branching is increasing your workload instead of making things easier you are most likely not using a source control system that is good at branching and merging.
While I don't have much to add, I have noticed at least two comments from you in this article stating that LVM snapshots are read-only. This is incorrect.
I apologize for my outdated knowledge. I very much remember them being read only in the LVM1 days. I imagine I have never made an attempt to mount a snapshot read/write since.
LVM2 is capable of a lot.
I would agree that it certainly does a lot, and I would be very upset if someone tried to take it away from me. It is just that we are to a point now where we've squeezed most of the possible functionality out of DM+LVM that we can.
Of course, the very same copy-on-write will also result in massive file fragmentation, carefully smearing your dbf files over the entire platters, making your SAN caches useless. Over time resulting in horrible read performance.
If you want good database performance you probably want as little file system overhead as possible between your database and the disk. I wouldn't have expected ZFS to be the most efficient place to store a database.
I would have to imagine your SAN is just doing uninformed readaheads. That would be a very good way to fill up a cache with useless data if you are reading from a fragmented file system.:)
This issue with copy-on-write will be entirely sidestepped in a few years by flash storage's lightning fast seek times and smarter caching. IIRC, isn't the reason that zfs-fuse uses so damn much ram because ZFS has its own caching logic built in? If the file system knows where all the blocks in a file are it can do readaheads on its own.
ZFS is certainly a huge improvement for anyone used to ufs and disksuite, but I have to say that using it in the real world it's not all it's cracked up to be.
I don't have enough of my own real world experience with ZFS to argue with your experience. In fact, what I know of how ZFS works makes me believe that it can cause exactly the problems of which you speak.
However, I don't think that means that there aren't a ton of workloads that wouldn't be impacted by these problems. I also believe that a large percentage of those workloads could benefit greatly from some of the features ZFS brings to the table.
RAID-Z is nice when you need write performance but can't afford the drives for RAID 10. I can think of plenty of times when it would have been nice to have a writable snapshot to chroot into.
Hell, I would even love to have ZFS on my laptop for snapshotting and cloning. It also seems like ZFS send/recv would make for much more efficient backups of my laptop than rsync buys me.
Mixing together the features of various layers is, imo, no matter how tempting, simply the wrong approach. Proceed further along that road and you get to record based filesystems or even more special-purpose variants. I mean, there are even more optimizations that you can do if you know the _contents_ of the files.
I think we are getting some pretty neat new features out of our file systems by blurring the lines between the layers. I wouldn't be surprised if we stumble upon a few more neat ideas before we're through.
There is still quite a bit of improvement to make even before we have to make the file system aware of what is inside our files.:)
Trivial example: If I want a copy-on-write snapshot, I have to set aside (ahead of time) some fixed amount of space that it can expand into. If I guess high, I waste space. If I guess low, I have to either expand it (somehow, if that's even possible) or lose my snapshot.
That still only covers one deficiency of LVM snapshots. LVM snapshots are read only and intended to be temporary. I'm also pretty sure you can't snapshot a snapshot, which wouldn't be at all helpful with a read only snapshot anyway.
A humble proposal: We need another layer, between the block layer and the filesystem layer -- call it an extent layer -- which is simply concerned with allocating some amount of space, and (perhaps) assigning it a unique ID. Filesystems could sit above this layer and implement whatever crazy optimizations or semantics they want -- linear vs btree vs whatever for directories, POSIX vs SQL, whatever.
We'd never be able to get it right and it would probably be more likely to get in the way. We seem to be learning that we can do much niftier things by tightly coupling what used to be very separate layers.
I haven't actually been seriously following filesystem development for years, so maybe this is already done. Or maybe it's a bad idea. If not, hopefully some kernel developers are reading this.
I don't really believe it is a bad idea. I do think it would have to be too heavy of a layer, though. It would have to track which file systems own each extent, and if you want to come close to matching RAID-Z you are going to need to be able to return very small extents (LVM defaults to 4MB, IIRC). If a file system is going to be requesting 4k extents you're going to have a lot of overhead in storing the extent ownership and size information. You're also going to have a lot of overhead in checking who owns each extent on any given read or write. I can think of ways to optimize that a bit, but I imagine it'll still have a significant space+performance impact.
I often hear that claim but never see any support of that claim.
The closest thing to RAID-Z in the Linux kernel is the RAID 5 DM. If you want to write a 4k block to some random location that isn't currently fully cached the DM has to read 1 stripe from each disk in the array, make the 4k change, recompute the checksums, and then flush that stripe back to each disk. The default stripe size is 64k. That means if you have 4 drives you would be performing a 256k read and a 256k write just to change a single 4k block. Of course, that is worst case. Best case is you have to overwrite the entire stripe with a fresh 256k block of data.
ZFS and RAID-Z get around that problem by just writing the changed blocks to an unused part of the disk. Once the write is complete it just moves the pointer to the new block location. This is copy-on-write, and this is where the performance boost comes in over RAID 5. With RAID-Z you should never be required to read the whole stripe to do a write.
RAID-Z also allows for dynamic stripe sizing. That helps get more optimal efficiency on small files and large files.
The dynamic stripes aren't terribly important, but if you could figure out a way to do the copy-on-write without the filesystem have very fine grained control and knowledge of the underlying array we would all love to hear about it:).
ZFS duplicates a lot of functionality that belongs outside of a filesystem. All of the above can already be done using any Linux filesystem, so why keep around a second copy of all that code that implements those features for just a single filesystem?
It wouldn't be possible to duplicate RAID-Z with LVM. Other features of ZFS are very handy, but RAID-Z is by far my favorite. Same storage density as RAID 5 but without the horrible write performance. RAID-Z uses copy-on-write to avoid RAID 5's required read for every non-cached write.
Being able to create filesystems just as easily as creating directories is quite handy as well, though. IIRC, the filesystem sizes in ZFS are controlled by a quota style system. That is much simpler than shrinking an LV (if your filesystem supports shrinking), then adding a new LV, and then creating a filesystem. I don't know about you, but I am always a bit nervous when I have to resize an LV.
That's terribly likely. Within short distance here I have 2 WRT54GL routers running Openwrt and OpenVPN. The one in this house currently claiming 246 days of uptime. That number actually surprises me greatly, I'd be willing to chalk it up to some sort of clock issue but I certainly don't remember the last time we actually power cycled it.
The one on the other end of the tunnel has an uptime of 27 days, I remember that it restarted during a power blip.
During my last job I deployed over 20 of these same routers running OpenVPN. Most of the offices had huge uptimes. The less stable offices had flaky internet connections (you get what you pay for, I suppose). In those offices, the VPN would sometimes drop overnight and not be able to reconnect without restarting OpenVPN. The nice ladies in the office would power cycle the router to make that happen.:)
I don't recall if/how we fixed the VPNs in those offices.
I do recall that a stock firmware on the WRT54GL (or G < v 5.0) has ridiculous settings ip_conntrack settings. I recall it being very easy for p2p apps to fill up the table and tie up any future NATed connections.
I bought two of these Fellowes Mighty 8 Outlet surge protectors for about 6 bucks each at a Big Lots. It is sort of triangle and it is pretty compact, but with the outlets arranged in such a way that you can pack quite a few wall warts into it. One of mine has 3 wall warts plugged into the outlets on top, and one in one of the lone side sockets. You could probably squeeze 7 clunky adapters into it and only block one outlet.
It was definately the best 6 dollars I've ever spent on a surge protector. I think it even has an 8 foot cord.
Another thing is, that the 1GHz CPU is really slow. I ran into problem when playing DivX or XVid movies.
My 933 Crusoe based laptop has been able to play 640x480 mpeg4 videos fullscreen under Linux for the 3+ years I have had it. I regularly watch 640x272(ish) videos on my laptop streamed over ssh (using the sshfs FUSE module) over my 802.11b network. That gives me a double encryption wammy, since my wireless driver does WEP in software.
My girlfriend's P3 700 laptop can do the same just fine. She also has a MythTV box, and she has no problem watching videos from the front end on her laptop over 802.11g.
If you go for MicroATX instead, you'll have just a slightly bigger case, however Standard components. There are zillion of cheap, reliable and silent CPU coolers, Power Supplies etc.
I don't really understand why size is a factor. Are people building $600 mini itx MythTV boxes to hook up to 20 inch TVs?:p
Plus any decent CPU, even a Pentium III 1 GHz is faster than this VIA processor.
Aren't the current Via processors a decendant of the old Cyrix processors? They are probably just have a poor FPU. I would be very surprised if it is so poor that a P3 700 could beat it, though.
...but aren't Mini-ITX boxes the usual form factor for MythTV implementations? If you're (typically) going to have a PVR in your living room, you'll want something that's low-power, quiet and preferably quite small.
I completely understand why quiet is important, but I don't really understand why it needs to be small. Most people that I know have quite a bit of room in the entertainment centers. Even if you don't, you might even be able to hide the box away behind the TV. The only thing that needs to be in plain sight is the IR receiver and probably the DVD driver. There is no reason not to just go USB or firewire for that.
If I were going to build a MythTV box today, I would probably start with a used 500-1000 mhz machine. Add a reasonably sized hard drive, a PVR 150 card, and possibly replace the video card. You certainly don't need a fancy video card, any old 2D card with a supported svideo output will do the trick. You could definitely do this for under 300 bucks, possibly even under $200.
I do not know how much a remote control and reciever will cost.:)
Saying you're getting doublecharged for Cable TV is a misnomer.
No, it isn't.
When you subscribe to Cable or Satellite service, the money you pay them goes to pay for their infastucture to deliver a service to you.
Yes, that is one thing that you pay for. Some amount of that money goes to each (most?) of the channels I am subscribing to. If the cable companies got them for free they would never leave out channels.
There's commercials during a program to pay for the channels' existence because they transmit their signal for free. Somebody's got to pay for all those FCC licences.
I completely understand why my local channels still have commercials when transmitted over my cable service. They do broadcast their signal for free and I could just as easily pick it up with a small antenna.
Cable/satellite only channels do NOT broadcast for free. They are paid by cable/satellite provider.
People who complain that they are getting doublecharged are doublystupid to whine that they are. Would you like some cheese with that?
People who complain that they are getting charged twice feel that the programming they are watching is only worth $50+ they are paying each month. I tend to agree with them. It doesn't seem right to pay to see advertisements (especially when 25% of the shows are ads). Just because you are happy to pay to watch advertisements doesn't mean everyone else is a sheep:p.
I've had Mandrake randomly delete all the kernels in my/boot partition randomly when I install Mozilla or mplayer or something completely harmless.
Thank you, I think you've helped back me up. I am assuming you were using apt? Apt can only be as good as the dependencies listed in the packages. When I moved from RPM based distros to Debian 6+ years ago I was very impressed with how much better things were in practice. At the time I had assumed it was because apt rocked. When RPM distros got apt I assumed Debian would lose its big advantage. It sounds like Debian's advantages weren't completely lost, just reduced.
Why? Not because they're stupid; they just have not been exposed to large computing jobs in the business world yet, or they're isolated from the ramifications of scheduling.
It is just as stupid to think that every piece of software needs to be 10% faster. If you have 10 web servers and you can make them server pages 10% faster you now only need 9. If you can make your simulation software run 10% faster you can save money on hardware (possibly quite a bit, of course).
You will get that 10% by optimizing your web server or your simulation software. Why on earth would you waste your time recompiling every single thing on the machine from source to do that? Does it matter if Bash runs 5% faster? Or cron? Probably not.
Many here think of an application (OOo Writer, M$ Word, Solitaire, Halo) opening 10% more quickly, or possibly a 10% faster framerate, and they Just. Don't. Get. It.
They don't get it in exactly the opposite way that you don't (seem) to get it. Since we are talking desktop use here, I'll think about my own desktop. The only things that actually use a significant amount of CPU (from most to least) for me here is video encoding (transcode), video playback (mplayer), and maybe Firefox and my X server.
Transcode can run for tens of hours at a time. It isn't worth the time to recompile, though, since I don't care when it finishes. Mplayer only uses a fraction of one of my CPUs and I can't make it play back any faster, so I won't recompile that... On my (slow) laptop, it uses 50+% CPU. I might consider it there, because it might drop my cpu speed down to the next notch.
Firefox can spin the CPU to the max for seconds at a time. I might notice a 10% increase in speed, if I could get it (especially on my laptop). In my case, that might be worth the rebuild. Too bad I don't have a way to objectively measure the speed (I tried once on my laptop, it didn't feel any faster:p). I would imagine optimizing OOo would be a reasonable idea for someone who uses it quite a bit.
My Ubuntu desktop has over 1600 packages installed... That isn't quite 1600 packages that need to be compiled, since a single program can be split up into multiple packages. I could probably hand build a half dozen of those packages (which is easy enough to do with dpkg) and I would notice 90% of the performance benefits of optimizing each package.
The Gentoo crowd will tell me that I would be saving memory if I could leave out support for libraries I don't use. They may be right, I have no idea. I would imagine a lot of that code just gets swapped out (or never even read into RAM).
kimvette, I have absolutely no idea how much of this is actually directed at you. I have been reading the comments and everyone seems to be 100% on one side or the other, when the optimal solution is likely in the middle. We have known this for a very long time though, back when I had a 386 everyone recommended compiling your own Linux kernel so as not to waste cpu/ram with stuff you'll never use:).
Do any of the kernels avaliable to apt rely on libc6? If you had an older kernel that relied on an older version of libc, then is it possible those would be uninstalled? Or would that take an "apt-get dist-upgrade"?
Yes, that would require a dist-upgrade. At least with Debian, I have no experience with apt and RPM based distros. I imagine it would be possible to define the package dependencies in a way that would make it think your system doesn't require a kernel... I don't think it could happen with Debian, though (unless they were trying something REALLY out there in unstable:p).
We're not talking about thousands of different binaries. We're talking about a plain simple "emerge MySQL". If MySQL is so fragile it can't handle that, then it's time for Postgres to step to the fore.
I don't think anyone is saying that it is unsafe to build MySQL from source. I think they are saying that it is just less stable when compiled with optimizations that are too aggressive. Plenty of software suffers from this problem.
I have no experience with Gentoo, so I can't make a statement as to the stability of a default install of MySQL in that environment. However, at the very least I would expect Gentoo's packaging system to be smart enough to not apply incompatible flags to packages it is building. As a user, I shouldn't have to know that MySQL doesn't work right with -O3. Is there a way to tell Gentoo something like "use -O3, but only if it is probably safe?"
Someone said this would turn into a "Debian vs Gentoo" debate. I happen to be on the Debian side of the fence, and I certainly won't argue that everything should be pre packaged. If you run a busy database or web server you will definitely see a noticable improvement if MySQL/PostgreSQL or Apache are optimized for your architecture. You don't need Gentoo for that, though. It is quite easy to compile your own packages from source (I don't like to install anything on my machines without making it a.deb first).
Basically, there's not much point in changing the existing OS if you want to keep your old hardware
Unless they are running something like Windows 95 that doesn't receive security patches anymore. If the machines are that old they probably won't run Windows XP very well, and if they won't run XP well they probably won't run a Gnome/KDE desktop very well either (I could be wrong, I don't use either of them). Old machines are probably a good candidate for a modern Linux distribution running something like XFCE.
And although Linux has gotten better over the years, it's still very difficult for newcomers to use effectively compared to Windows.
I don't know how true that is, my parents had very little trouble making the switch. I would imagine children 50+ years younger than my parents would have a much easier time adapting.
The kids would be just as challenged in my opinion, particularly if you want to teach them stuff like file management and system configuration.
Why exactly would you teach them this? I've been out of school for 10 years now, but I would imagine most students would be learning about office type applications.
In conclusion, if it aint broke, don't fix it. If you're buying new systems, it might be worth considering getting a different OS, but I wouldn't trash Windows just for the sake of it, as most people will have some trouble.
If they don't have security updates they are dealing with a broken OS, especially if they are running it on semi-public machines with internet access.
Slashdot Mirror
I'm old enough to have learned how to navigate without GPS or even maps. I use GPS nowadays
Jesus Christ Potatoes! How old ARE you?! They had already invented maps long before I was old enough to drive!
I've been using Seafile since April and I am very, very pleased with it. It is one of the few self hosted options that supports client side encryption and manages to scale up to a reasonably large number of files. It fell down on me in the 100k file range, but I was able to get around that issue by breaking my data up into smaller libraries.
The client side encryption was slightly problematic in the 1.x releases. Back then, you had to type your encryption passphrase into the server to create a new library. As of 2.0 you can create new libraries in the client without your passphrase leaving your local machine. You still can't dig through your file revision history without giving the server your passphrase; hopefully that functionality will be integrated into the client in the future.
I took a quick look at SparkleShare, ownCloud, and BitTorrent Sync, but none of them were a good fit for me. BitTorrent Sync only encrypts your data while it is in flight, ownCloud only supports server side encryption, and you can't properly store Git repos under SparkleShare.
It is a very bright, and I think it looks quite amazing. It is especially amazing at its sub-$350 price point. I'm pretty jealous of it, but my laptop lacks the dual link DVI port required for driving one of these displays. I would really like to upgrade from my pair of 1080p monitors to a pair of these! He wrote about his 27" 2560x1440 monitor on his blog.
In some states, an adult is legally required to provide ID to any cop who asks - it's actually illegal to walk down the street without a driver's license (or non-driver's ID). We seem to have little regard for the Constitution.
You would be incorrect.
http://en.wikipedia.org/wiki/Stop_and_Identify_statutes
Are you saying that all my laptops with pci-e video chipsets should be failing to suspend? Suspend and hibernate have worked fine on all my laptops for many years with Ubuntu, 8.10 or otherwise.
It might be worth looking for the bug if you are more specific about the problem since there certainly isn't a suspend problem with every pci-e equipped machine.
The only thing that I dislike after resuming from a suspend is waiting for the damned wifi to connect. Resume takes 2-3 seconds or less. Reconnecting sometimes seems to take forever, especially in busy apartment complexes with 20+ aps in range.
If that is true then at least one of them isn't actually generating an MD5 hash.
I'm just guessing, but I bet you were also encoding the line ending characters. That would be encoded differently on Windows and UNIX, so you'd actually be hashing two strings that differed by at least one byte.
Where do you keep things that you don't think are stable? Are you expecting that code to become stable at some point? If the code is eventually meant to go into production then your RCS is probably a good place to keep it while you're working on it.
I can only imagine that branching+merging is more difficult with your RCS than checking out a fresh copy. Either that, or you rarely have to check in a bug fix while you're in the middle of a "2-3 week" change.
I bet most people would agree with you.
Depends if he's laying down or if he's perpendicular.
I constantly branch and merge even when I am the only one working on a codebase. When branching and merging are so easy why wouldn't you take advantage of it? Of course, it is always possible that I have a dysfunctional relation with myself.
I can't speak for how awesome git is, I've never used it.
If branching is increasing your workload instead of making things easier you are most likely not using a source control system that is good at branching and merging.
I apologize for my outdated knowledge. I very much remember them being read only in the LVM1 days. I imagine I have never made an attempt to mount a snapshot read/write since.
I would agree that it certainly does a lot, and I would be very upset if someone tried to take it away from me. It is just that we are to a point now where we've squeezed most of the possible functionality out of DM+LVM that we can.
If you want good database performance you probably want as little file system overhead as possible between your database and the disk. I wouldn't have expected ZFS to be the most efficient place to store a database.
I would have to imagine your SAN is just doing uninformed readaheads. That would be a very good way to fill up a cache with useless data if you are reading from a fragmented file system. :)
This issue with copy-on-write will be entirely sidestepped in a few years by flash storage's lightning fast seek times and smarter caching. IIRC, isn't the reason that zfs-fuse uses so damn much ram because ZFS has its own caching logic built in? If the file system knows where all the blocks in a file are it can do readaheads on its own.
I don't have enough of my own real world experience with ZFS to argue with your experience. In fact, what I know of how ZFS works makes me believe that it can cause exactly the problems of which you speak.
However, I don't think that means that there aren't a ton of workloads that wouldn't be impacted by these problems. I also believe that a large percentage of those workloads could benefit greatly from some of the features ZFS brings to the table.
RAID-Z is nice when you need write performance but can't afford the drives for RAID 10. I can think of plenty of times when it would have been nice to have a writable snapshot to chroot into.
Hell, I would even love to have ZFS on my laptop for snapshotting and cloning. It also seems like ZFS send/recv would make for much more efficient backups of my laptop than rsync buys me.
I think we are getting some pretty neat new features out of our file systems by blurring the lines between the layers. I wouldn't be surprised if we stumble upon a few more neat ideas before we're through.
There is still quite a bit of improvement to make even before we have to make the file system aware of what is inside our files. :)
That still only covers one deficiency of LVM snapshots. LVM snapshots are read only and intended to be temporary. I'm also pretty sure you can't snapshot a snapshot, which wouldn't be at all helpful with a read only snapshot anyway.
We'd never be able to get it right and it would probably be more likely to get in the way. We seem to be learning that we can do much niftier things by tightly coupling what used to be very separate layers.
I don't really believe it is a bad idea. I do think it would have to be too heavy of a layer, though. It would have to track which file systems own each extent, and if you want to come close to matching RAID-Z you are going to need to be able to return very small extents (LVM defaults to 4MB, IIRC). If a file system is going to be requesting 4k extents you're going to have a lot of overhead in storing the extent ownership and size information. You're also going to have a lot of overhead in checking who owns each extent on any given read or write. I can think of ways to optimize that a bit, but I imagine it'll still have a significant space+performance impact.
The closest thing to RAID-Z in the Linux kernel is the RAID 5 DM. If you want to write a 4k block to some random location that isn't currently fully cached the DM has to read 1 stripe from each disk in the array, make the 4k change, recompute the checksums, and then flush that stripe back to each disk. The default stripe size is 64k. That means if you have 4 drives you would be performing a 256k read and a 256k write just to change a single 4k block. Of course, that is worst case. Best case is you have to overwrite the entire stripe with a fresh 256k block of data.
ZFS and RAID-Z get around that problem by just writing the changed blocks to an unused part of the disk. Once the write is complete it just moves the pointer to the new block location. This is copy-on-write, and this is where the performance boost comes in over RAID 5. With RAID-Z you should never be required to read the whole stripe to do a write.
RAID-Z also allows for dynamic stripe sizing. That helps get more optimal efficiency on small files and large files.
The dynamic stripes aren't terribly important, but if you could figure out a way to do the copy-on-write without the filesystem have very fine grained control and knowledge of the underlying array we would all love to hear about it :).
It wouldn't be possible to duplicate RAID-Z with LVM. Other features of ZFS are very handy, but RAID-Z is by far my favorite. Same storage density as RAID 5 but without the horrible write performance. RAID-Z uses copy-on-write to avoid RAID 5's required read for every non-cached write.
Being able to create filesystems just as easily as creating directories is quite handy as well, though. IIRC, the filesystem sizes in ZFS are controlled by a quota style system. That is much simpler than shrinking an LV (if your filesystem supports shrinking), then adding a new LV, and then creating a filesystem. I don't know about you, but I am always a bit nervous when I have to resize an LV.
You're doing it wrong.
That's terribly likely. Within short distance here I have 2 WRT54GL routers running Openwrt and OpenVPN. The one in this house currently claiming 246 days of uptime. That number actually surprises me greatly, I'd be willing to chalk it up to some sort of clock issue but I certainly don't remember the last time we actually power cycled it.
The one on the other end of the tunnel has an uptime of 27 days, I remember that it restarted during a power blip.
During my last job I deployed over 20 of these same routers running OpenVPN. Most of the offices had huge uptimes. The less stable offices had flaky internet connections (you get what you pay for, I suppose). In those offices, the VPN would sometimes drop overnight and not be able to reconnect without restarting OpenVPN. The nice ladies in the office would power cycle the router to make that happen. :)
I don't recall if/how we fixed the VPNs in those offices.
I do recall that a stock firmware on the WRT54GL (or G < v 5.0) has ridiculous settings ip_conntrack settings. I recall it being very easy for p2p apps to fill up the table and tie up any future NATed connections.
I bought two of these Fellowes Mighty 8 Outlet surge protectors for about 6 bucks each at a Big Lots. It is sort of triangle and it is pretty compact, but with the outlets arranged in such a way that you can pack quite a few wall warts into it. One of mine has 3 wall warts plugged into the outlets on top, and one in one of the lone side sockets. You could probably squeeze 7 clunky adapters into it and only block one outlet.
It was definately the best 6 dollars I've ever spent on a surge protector. I think it even has an 8 foot cord.
Another thing is, that the 1GHz CPU is really slow. I ran into problem when playing DivX or XVid movies.
My 933 Crusoe based laptop has been able to play 640x480 mpeg4 videos fullscreen under Linux for the 3+ years I have had it. I regularly watch 640x272(ish) videos on my laptop streamed over ssh (using the sshfs FUSE module) over my 802.11b network. That gives me a double encryption wammy, since my wireless driver does WEP in software.
My girlfriend's P3 700 laptop can do the same just fine. She also has a MythTV box, and she has no problem watching videos from the front end on her laptop over 802.11g.
If you go for MicroATX instead, you'll have just a slightly bigger case, however Standard components. There are zillion of cheap, reliable and silent CPU coolers, Power Supplies etc.
I don't really understand why size is a factor. Are people building $600 mini itx MythTV boxes to hook up to 20 inch TVs? :p
Plus any decent CPU, even a Pentium III 1 GHz is faster than this VIA processor.
Aren't the current Via processors a decendant of the old Cyrix processors? They are probably just have a poor FPU. I would be very surprised if it is so poor that a P3 700 could beat it, though.
I completely understand why quiet is important, but I don't really understand why it needs to be small. Most people that I know have quite a bit of room in the entertainment centers. Even if you don't, you might even be able to hide the box away behind the TV. The only thing that needs to be in plain sight is the IR receiver and probably the DVD driver. There is no reason not to just go USB or firewire for that.
If I were going to build a MythTV box today, I would probably start with a used 500-1000 mhz machine. Add a reasonably sized hard drive, a PVR 150 card, and possibly replace the video card. You certainly don't need a fancy video card, any old 2D card with a supported svideo output will do the trick. You could definitely do this for under 300 bucks, possibly even under $200.
I do not know how much a remote control and reciever will cost. :)
printing it out and taking it to coffee shops helps too, and it makes you look hella nerdy.
What is this "paper" of which you speak?
Saying you're getting doublecharged for Cable TV is a misnomer.
No, it isn't.
When you subscribe to Cable or Satellite service, the money you pay them goes to pay for their infastucture to deliver a service to you.
Yes, that is one thing that you pay for. Some amount of that money goes to each (most?) of the channels I am subscribing to. If the cable companies got them for free they would never leave out channels.
There's commercials during a program to pay for the channels' existence because they transmit their signal for free. Somebody's got to pay for all those FCC licences.
I completely understand why my local channels still have commercials when transmitted over my cable service. They do broadcast their signal for free and I could just as easily pick it up with a small antenna.
Cable/satellite only channels do NOT broadcast for free. They are paid by cable/satellite provider.
People who complain that they are getting doublecharged are doublystupid to whine that they are. Would you like some cheese with that?
People who complain that they are getting charged twice feel that the programming they are watching is only worth $50+ they are paying each month. I tend to agree with them. It doesn't seem right to pay to see advertisements (especially when 25% of the shows are ads). Just because you are happy to pay to watch advertisements doesn't mean everyone else is a sheep :p.
I've had Mandrake randomly delete all the kernels in my /boot partition randomly when I install Mozilla or mplayer or something completely harmless.
Thank you, I think you've helped back me up. I am assuming you were using apt? Apt can only be as good as the dependencies listed in the packages. When I moved from RPM based distros to Debian 6+ years ago I was very impressed with how much better things were in practice. At the time I had assumed it was because apt rocked. When RPM distros got apt I assumed Debian would lose its big advantage. It sounds like Debian's advantages weren't completely lost, just reduced.
Why? Not because they're stupid; they just have not been exposed to large computing jobs in the business world yet, or they're isolated from the ramifications of scheduling.
It is just as stupid to think that every piece of software needs to be 10% faster. If you have 10 web servers and you can make them server pages 10% faster you now only need 9. If you can make your simulation software run 10% faster you can save money on hardware (possibly quite a bit, of course).
You will get that 10% by optimizing your web server or your simulation software. Why on earth would you waste your time recompiling every single thing on the machine from source to do that? Does it matter if Bash runs 5% faster? Or cron? Probably not.
Many here think of an application (OOo Writer, M$ Word, Solitaire, Halo) opening 10% more quickly, or possibly a 10% faster framerate, and they Just. Don't. Get. It.
They don't get it in exactly the opposite way that you don't (seem) to get it. Since we are talking desktop use here, I'll think about my own desktop. The only things that actually use a significant amount of CPU (from most to least) for me here is video encoding (transcode), video playback (mplayer), and maybe Firefox and my X server.
Transcode can run for tens of hours at a time. It isn't worth the time to recompile, though, since I don't care when it finishes. Mplayer only uses a fraction of one of my CPUs and I can't make it play back any faster, so I won't recompile that... On my (slow) laptop, it uses 50+% CPU. I might consider it there, because it might drop my cpu speed down to the next notch.
Firefox can spin the CPU to the max for seconds at a time. I might notice a 10% increase in speed, if I could get it (especially on my laptop). In my case, that might be worth the rebuild. Too bad I don't have a way to objectively measure the speed (I tried once on my laptop, it didn't feel any faster :p). I would imagine optimizing OOo would be a reasonable idea for someone who uses it quite a bit.
My Ubuntu desktop has over 1600 packages installed... That isn't quite 1600 packages that need to be compiled, since a single program can be split up into multiple packages. I could probably hand build a half dozen of those packages (which is easy enough to do with dpkg) and I would notice 90% of the performance benefits of optimizing each package.
The Gentoo crowd will tell me that I would be saving memory if I could leave out support for libraries I don't use. They may be right, I have no idea. I would imagine a lot of that code just gets swapped out (or never even read into RAM).
kimvette, I have absolutely no idea how much of this is actually directed at you. I have been reading the comments and everyone seems to be 100% on one side or the other, when the optimal solution is likely in the middle. We have known this for a very long time though, back when I had a 386 everyone recommended compiling your own Linux kernel so as not to waste cpu/ram with stuff you'll never use :).
Do any of the kernels avaliable to apt rely on libc6? If you had an older kernel that relied on an older version of libc, then is it possible those would be uninstalled? Or would that take an "apt-get dist-upgrade"?
Yes, that would require a dist-upgrade. At least with Debian, I have no experience with apt and RPM based distros. I imagine it would be possible to define the package dependencies in a way that would make it think your system doesn't require a kernel... I don't think it could happen with Debian, though (unless they were trying something REALLY out there in unstable :p).
We're not talking about thousands of different binaries. We're talking about a plain simple "emerge MySQL". If MySQL is so fragile it can't handle that, then it's time for Postgres to step to the fore.
I don't think anyone is saying that it is unsafe to build MySQL from source. I think they are saying that it is just less stable when compiled with optimizations that are too aggressive. Plenty of software suffers from this problem.
I have no experience with Gentoo, so I can't make a statement as to the stability of a default install of MySQL in that environment. However, at the very least I would expect Gentoo's packaging system to be smart enough to not apply incompatible flags to packages it is building. As a user, I shouldn't have to know that MySQL doesn't work right with -O3. Is there a way to tell Gentoo something like "use -O3, but only if it is probably safe?"
Someone said this would turn into a "Debian vs Gentoo" debate. I happen to be on the Debian side of the fence, and I certainly won't argue that everything should be pre packaged. If you run a busy database or web server you will definitely see a noticable improvement if MySQL/PostgreSQL or Apache are optimized for your architecture. You don't need Gentoo for that, though. It is quite easy to compile your own packages from source (I don't like to install anything on my machines without making it a .deb first).
Basically, there's not much point in changing the existing OS if you want to keep your old hardware
Unless they are running something like Windows 95 that doesn't receive security patches anymore. If the machines are that old they probably won't run Windows XP very well, and if they won't run XP well they probably won't run a Gnome/KDE desktop very well either (I could be wrong, I don't use either of them). Old machines are probably a good candidate for a modern Linux distribution running something like XFCE.
And although Linux has gotten better over the years, it's still very difficult for newcomers to use effectively compared to Windows.
I don't know how true that is, my parents had very little trouble making the switch. I would imagine children 50+ years younger than my parents would have a much easier time adapting.
The kids would be just as challenged in my opinion, particularly if you want to teach them stuff like file management and system configuration.
Why exactly would you teach them this? I've been out of school for 10 years now, but I would imagine most students would be learning about office type applications.
In conclusion, if it aint broke, don't fix it. If you're buying new systems, it might be worth considering getting a different OS, but I wouldn't trash Windows just for the sake of it, as most people will have some trouble.
If they don't have security updates they are dealing with a broken OS, especially if they are running it on semi-public machines with internet access.