> > I have to say it never occurred to me that there might be users > of RedSleeve that don't have another Linux system up and running > already. Expending any effort specifically for Windows-only users > seems like a poor use of resources considering the target > audience. RedSleeve most certainly isn't aimed at beginners. >
While I am in a more windows-centric environment at the moment (not entirely by choice), I am not strictly windows-only. I do have a couple of linux systems, such as my server I mentioned earlier. However, as they run headless in a rack, it's much less convenient to attach usb devices to them than it is to my desktop. I do also run VMWare Workstation, and have linux VMs in it, but I tend to have issues sometimes with writing to a block device in its passthrough mode. At no time did I ever figure RedSleeve for the beginner--most beginners will just accept starting out with Raspbian (for RPi users), or even the NOOBS card image that's becoming so popular lately. Personally, I'm quite comfortable with with most things linux (struggling a bit with systemd though :) ), I've been working with it professionally for over 10 years now, and personally tinkering with it for almost 15. In my case, my desktop is Windows because there are some windows specific programs I need to run. I'd considered dual booting, but with how much I multitask, that was too much of a pain, so I opted for VMWare Workstation. If I had the money, I'd probably get a secondary desktop specific for linux, but for now, I don't. Granted, I may not strictly be the norm, but I do think it is folly to assume that I am the exception either. But for the few systems that we have hardware and suitable > kernels available for, IMO, if we're going to make dd-able > images, they might as well be for a configuration that involves > some additional process that may not be obvious to everyone > such as making it run on a decent file system. Fair enough. I did not initially realize that you were planning on changing how you did your releases. I would certainly prefer a zfs-based image to none ;) > I understand your concern, but do your applications do heavy disk > I/O while number crunching that hard? On a 2GHz Marvell Kirkwood I > find that zfs send/receive tops out at about 30MB/s, partially > because netcat seems to be eating upward of 20% of system CPU time > (even when it is piping to /dev/null, not a zfs-fuse related issue). > Scrubbing the FS goes at about 50MB/s, purely CPU bound. While that > is not exactly stellar, it is certainly far more than you would > achieve on typical general purpose system random seek pattern on > spinning rust. > > I would be quite interested to see empirical evidence for your > intended load. The zfs-fuse package is on the mirrors. Perhaps > add a scratch disk, zfs it up and see how it behaves under realistic > application load vs. other FS-es? The final application which I intend to run on my (eventual) product hasn't been developed yet, so I can't quite help there just yet. ;) But it is going to be a load rather similar to what one would see with video transcoding, and pattern recognition. Which, granted, I don't believe will be super disk I/O intensive, but only time (well, ok, and some developers ;) ) will tell whether or not it will be an issue. -- --Mark
_______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
