Re: [gentoo-user] merging pdf file into one page
On Sat, Jan 24, 2015 at 1:26 PM, Joseph syscon...@gmail.com wrote: I've pdf form that I print. Once the form is printed I put it back in the printer tray and print information over top of it. It worked in the past but after I print it second time (over the printed form) the pages look as if they came out of the washing machine. They are crumpled. I think it as to do something with the static. How to I combine (overlap) two pdf files into one page. Load both PDF files in Inkscape, adjust slightly if necessary so everything aligns, and export the resulting file to PDF. You can convert the PDF files to SVG before loading to Inkscape, if the Inkscape converter is not up to your standards. You can use media-gfx/pdf2svg for that. What I do nowadays (if I have a PDF to fill that has no forms), is to load the PDF in Inkscape, and fill it with the text tool. Then print it or export it to SVG or PDF if I want to keep it. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] merging pdf file into one page
On 01/24/15 13:34, Canek Peláez Valdés wrote: On Sat, Jan 24, 2015 at 1:26 PM, Joseph [1]syscon...@gmail.com wrote: I've pdf form that I print. Once the form is printed I put it back in the printer tray and print information over top of it. It worked in the past but after I print it second time (over the printed form) the pages look as if they came out of the washing machine. They are crumpled. I think it as to do something with the static. How to I combine (overlap) two pdf files into one page. Load both PDF files in Inkscape, adjust slightly if necessary so everything aligns, and export the resulting file to PDF. You can convert the PDF files to SVG before loading to Inkscape, if the Inkscape converter is not up to your standards. You can use media-gfx/pdf2svg for that. What I do nowadays (if I have a PDF to fill that has no forms), is to load the PDF in Inkscape, and fill it with the text tool. Then print it or export it to SVG or PDF if I want to keep it. Regards. What I'm looking for I think it is called stitching two pdf files. -- Joseph
Re: [gentoo-user] Re: Get off my lawn?
Hi, Rich. On Sat, Jan 24, 2015 at 12:58:48PM -0500, Rich Freeman wrote: On Sat, Jan 24, 2015 at 12:27 PM, Alan Mackenzie a...@muc.de wrote: On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote: Do you regularly update the software on your embedded system? systemd-183 hasn't changed a bit since the day it was released. systemd-183's velocity is unchanged from the day it was released, and it isn't slow. You'll have to define what you mean by velocity here, not that it really matters since we can quibble over definitions all day long. systemd-183 today is identical to systemd-183 the day it was released. It is a snapshot in time. When you take a photograph (a snapshot) of a fast moving thing, the photo may give the false appearance of the thing being stationary, whereas it is in reality a fast moving object. That is my feeling about systemd. But I agree, the point is not worth quibbling over. The fast-moving target bit is only an issue if you want to keep updating it. Quite the contrary - the fast-moving bit is an issue if you _can't_ update it, or if updating is expensive, which is frequently the case for embedded systems. Fast-moving software is likelier to be buggy than well established traditional software. You do test your embedded devices before you release them, right? Absolutely. They are tested most searchingly, both by us and by the customer. However software not written by us is assumed to be fully tested by its suppliers, hence is only tested by us at the System Integration level. Generally, that's a safe assumption when speaking about proprietary embedded OSs. Clearly, SW which incorporates GPL bits must itself be GPL, and I have no experience of working on any such embedded SW. That said, systemd doesn't change THAT much between versions as far as the key interfaces go. But busybox changes even less. It is also used far less. Are you sure? I had the impression that busybox was very widely used on embedded devices, such as routers, which are made in very large numbers. Do you really think that you're less likely to have problems with busybox mdev and busybox init than with whatever version of backported version of systemd RHEL is using six months after release? Yes, I do, certainly on an embedded system. Even on a desktop, mdev works well. I've used it. The only reason I gave up on it was because a package I use (I can't remember which one any more) suddenly acquired a hard dependency on udev. :-( -- Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Calculating dependencies...: Any way to make it faster?
Neil Bothwick wrote: On Sat, 24 Jan 2015 07:03:30 +0100, Tomas Mozes wrote: Binary packages: http://thread.gmane.org/gmane.linux.gentoo.devel/94176 In my experience, using the -k or -K option makes emerge take longer to calculate the package list, which makes sense as it also needs to check the availability of packages. You could try a lower --backtrack value, but the time saved may be more than lost again when it causes problems. Setting the backtrack to a lower value was all I could think of too. Other than that, I think it just needs horsepower under the hood. This topic reminds me of when I was installing Gentoo on a 133 MHz machine with around 256MBs of ram. It's been a while but still, it was slow. Dale :-) :-)
Re: [gentoo-user] Latest chromium-40 on ~x86
On Saturday 24 January 2015 16:43:41 Nils Holland wrote: I've been using chromium successfully on my ~x86 system for quite a long time, but starting with the last two updates that came in during the last few days (namely, chromium-40.0.2214.85 and chromium-40.0.2214.91), I started having problems. ---8 The question, thus, would probably be: Anyone using one of the recent chromium-40 versions on ~x86 or anywhere else and seeing something similar? Or probably someone who has experienced something like that before and could offer a guess what might be wrong here - a real bug, custom-cflags, or something entirely different? This is and amd64 box, not ~x86, but chromium-40.0.2214.91 is working fine here. It's not been running more than a few hours since today's upgrade, but at least it does run. -- Rgds Peter.
Re: [gentoo-user] SMART drive test results, 2.0 for same drive as before.
Nils Holland wrote: On Sat, Jan 24, 2015 at 11:29:53AM -0600, Dale wrote: Well, I have dd'd the thing a few times and ran the tests again, it still gives errors. What's odd, they seem to move around. Is there a bug crawling around in my drive?? lol # 1 Extended offlineCompleted: read failure 40% 21500 4032048552 #12 Extended offlineCompleted: read failure 40% 21406 4032272464 Well, the location of the first unreadable error is before the location of the second one, so it's entirely possible that the drive was eventually able to read the first bad sector and subsequently remapped it to a sparse sector. Of, depending on what other actions may have been done to the drive between the two tests shown, a write may have been done to the sector, which would also result immediately in a sparse sector being taken if the original sector looks suspicious to the drive. All of that should - at least a little bit of it - be visible by looking at the other smart statictics. The reallocated sector count would have gone up in such a case, and the number of currently pending sectors could have gone down. Still, even though the first bad sector might have been appropriately dealt with, there's obviously more wrong with the drive, as the second test shows. Personally, with the relatively low hard disk prices of recent years, I've always started distrusting drives as soon as they began showing bad / remapped sectors and failing self-tests, even though they still reported their own SMART status as fine. More times than not, just completely zeroing out a drive will fix the then-known bad sectors, as it triggers the drive's firmware to remap them, but in my experience a drive that started developing a few bad sectors will soon develop more of the same. So at least in environments dealing with important data, I'd quickly exchange such a drive and probably only continue to use it for less important stuff, like transferring data from one machine to another, where the failure of the transpoting drive would be harmless, as the data could at any time be gotten again from the original machine carrying it. Greetings, Nils This drive did report issues a while back, year or so I guess, and I got them corrected by dd'ing the drive etc. Anyway, I bought a new drive to replace it but have been using the one here as a backup drive mostly to test and just see what it would do long term. Well, it did last a while at least but as you rightly point out, it started having more issues. At least in this case, once the drive reported errors, it went downhill from there. I was sort of hoping it would work fine like one would expect but I'm not surprised that it is failing again. One thing I have learned about drives over the years, if it ever gets a error, you better replace it, just to be safe if nothing else. Since I already replaced this drive, nothing lost. We did learn something tho. Just because it claims to have fixed itself doesn't mean it will be a long term solution. ;-) Dale :-) :-)
[gentoo-user] merging pdf file into one page
I've pdf form that I print. Once the form is printed I put it back in the printer tray and print information over top of it. It worked in the past but after I print it second time (over the printed form) the pages look as if they came out of the washing machine. They are crumpled. I think it as to do something with the static. How to I combine (overlap) two pdf files into one page. -- Joseph
Re: [gentoo-user] merging pdf file into one page
On 01/24/2015 10:29 PM, Joseph wrote: Join in1.pdf and in2.pdf into a new PDF, out1.pdf: That was only description of the actual command that followed ...
Re: [gentoo-user] merging pdf file into one page
On 01/24/15 22:03, Thanasis wrote: On 01/24/2015 09:47 PM, Joseph wrote: What I'm looking for I think it is called stitching two pdf files. Join in1.pdf and in2.pdf into a new PDF, out1.pdf: pdftk in1.pdf in2.pdf cat output out1.pdf https://www.pdflabs.com/docs/pdftk-cli-examples/ http://www.maketecheasier.com/combine-multiple-pdf-files-with-pdftk/ join complain about sorting: join 1.pdf t4-flat-02b.pdf join: 1.pdf:3: is not sorted: I'm compiling pdftk. -- Joseph
Re: [gentoo-user] Re: Get off my lawn?
On Sat, Jan 24, 2015 at 12:27 PM, Alan Mackenzie a...@muc.de wrote: On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote: Do you regularly update the software on your embedded system? systemd-183 hasn't changed a bit since the day it was released. systemd-183's velocity is unchanged from the day it was released, and it isn't slow. You'll have to define what you mean by velocity here, not that it really matters since we can quibble over definitions all day long. systemd-183 today is identical to systemd-183 the day it was released. It is a snapshot in time. The fast-moving target bit is only an issue if you want to keep updating it. Quite the contrary - the fast-moving bit is an issue if you _can't_ update it, or if updating is expensive, which is frequently the case for embedded systems. Fast-moving software is likelier to be buggy than well established traditional software. You do test your embedded devices before you release them, right? That said, systemd doesn't change THAT much between versions as far as the key interfaces go. But busybox changes even less. It is also used far less. Do you really think that you're less likely to have problems with busybox mdev and busybox init than with whatever version of backported version of systemd RHEL is using six months after release? -- Rich
Re: [gentoo-user] merging pdf file into one page
On 01/24/15 22:03, Thanasis wrote: On 01/24/2015 09:47 PM, Joseph wrote: What I'm looking for I think it is called stitching two pdf files. Join in1.pdf and in2.pdf into a new PDF, out1.pdf: pdftk in1.pdf in2.pdf cat output out1.pdf https://www.pdflabs.com/docs/pdftk-cli-examples/ http://www.maketecheasier.com/combine-multiple-pdf-files-with-pdftk/ It did not work. pdftk 1.pdf t4-flat-02b.pdf cat output out1.pdf did the same as pdfjoin. It generated document with two pages. I don't want to combine them together (have two pages). I want to stitch them, two pages into one page. -- Joseph
Re: [gentoo-user] merging pdf file into one page
On Sat, 24 Jan 2015 12:47:14 -0700, Joseph wrote: What I'm looking for I think it is called stitching two pdf files. app-text/pdftk -- Neil Bothwick I laugh in the face of danger, then I hide until it goes away pgpf9LFpXzMLL.pgp Description: OpenPGP digital signature
Re: [gentoo-user] merging pdf file into one page
On Sat, 24 Jan 2015 13:40:32 -0700, Joseph wrote: pdftk 1.pdf t4-flat-02b.pdf cat output out1.pdf did the same as pdfjoin. It generated document with two pages. I don't want to combine them together (have two pages). I want to stitch them, two pages into one page. Look at the background and stamp operations. In fact, look at the whole man page. -- Neil Bothwick Sacred cows make great hamburgers. pgpdHpKOn_QLz.pgp Description: OpenPGP digital signature
Re: [gentoo-user] SMART drive test results, 2.0 for same drive as before.
On Sat, Jan 24, 2015 at 11:29:53AM -0600, Dale wrote: Well, I have dd'd the thing a few times and ran the tests again, it still gives errors. What's odd, they seem to move around. Is there a bug crawling around in my drive?? lol # 1 Extended offlineCompleted: read failure 40% 21500 4032048552 #12 Extended offlineCompleted: read failure 40% 21406 4032272464 Well, the location of the first unreadable error is before the location of the second one, so it's entirely possible that the drive was eventually able to read the first bad sector and subsequently remapped it to a sparse sector. Of, depending on what other actions may have been done to the drive between the two tests shown, a write may have been done to the sector, which would also result immediately in a sparse sector being taken if the original sector looks suspicious to the drive. All of that should - at least a little bit of it - be visible by looking at the other smart statictics. The reallocated sector count would have gone up in such a case, and the number of currently pending sectors could have gone down. Still, even though the first bad sector might have been appropriately dealt with, there's obviously more wrong with the drive, as the second test shows. Personally, with the relatively low hard disk prices of recent years, I've always started distrusting drives as soon as they began showing bad / remapped sectors and failing self-tests, even though they still reported their own SMART status as fine. More times than not, just completely zeroing out a drive will fix the then-known bad sectors, as it triggers the drive's firmware to remap them, but in my experience a drive that started developing a few bad sectors will soon develop more of the same. So at least in environments dealing with important data, I'd quickly exchange such a drive and probably only continue to use it for less important stuff, like transferring data from one machine to another, where the failure of the transpoting drive would be harmless, as the data could at any time be gotten again from the original machine carrying it. Greetings, Nils
Re: [gentoo-user] merging pdf file into one page
On 01/24/2015 09:47 PM, Joseph wrote: What I'm looking for I think it is called stitching two pdf files. Join in1.pdf and in2.pdf into a new PDF, out1.pdf: pdftk in1.pdf in2.pdf cat output out1.pdf https://www.pdflabs.com/docs/pdftk-cli-examples/ http://www.maketecheasier.com/combine-multiple-pdf-files-with-pdftk/
Re: [gentoo-user] merging pdf file into one page
On 01/24/15 20:50, Neil Bothwick wrote: On Sat, 24 Jan 2015 13:40:32 -0700, Joseph wrote: pdftk 1.pdf t4-flat-02b.pdf cat output out1.pdf did the same as pdfjoin. It generated document with two pages. I don't want to combine them together (have two pages). I want to stitch them, two pages into one page. Look at the background and stamp operations. In fact, look at the whole man page. -- Neil Bothwick Sacred cows make great hamburgers. Thanks, yes it worked with stamp and background pdftk t4-flat-02b.pdf stamp 1.pdf output out1.pdf -- Joseph
[gentoo-user] problem emerging Libdrm
After exactly 2 years , I'm trying to update my Asus EEE netbook. I've emerged gcc-4.8.3 ( 3 h 31 m ), portage-2.2.14 udev-216 . However, I've lost X : trying to update gtk+ , I've run into a problem : it requires Mesa Cairo both require libdrm-2.4.58 , which refuses to compile, failing with lines reporting that libpng15.so.15 libudev.so.0 not found, which seem to be needed by Cairo Mesa, which depend on Libdrm ; I've already updated to libpng-1.6.16 , so libpng16.so.16 is installed. I've tried 'emerge --nodeps' with Cairo Mesa, but both fail. libdrm-2.4.58 was emerged on this desktop machine without any difficulty with libpng-1.6.16 emerged a bit later everything working properly. I've done searches of Bugs, Forum asked Google without much help. Can anyone suggest what might be causing this problem ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Re: Get off my lawn?
On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer m...@marc-stuermer.de wrote: Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target. Do you regularly update the software on your embedded system? systemd-183 hasn't changed a bit since the day it was released. The fast-moving target bit is only an issue if you want to keep updating it. That said, systemd doesn't change THAT much between versions as far as the key interfaces go. -- Rich
Re: [gentoo-user] merging pdf file into one page
On 25/01/15 03:47, Joseph wrote: On 01/24/15 13:34, Canek Peláez Valdés wrote: On Sat, Jan 24, 2015 at 1:26 PM, Joseph [1]syscon...@gmail.com wrote: I've pdf form that I print. Once the form is printed I put it back in the printer tray and print information over top of it. It worked in the past but after I print it second time (over the printed form) the pages look as if they came out of the washing machine. They are crumpled. I think it as to do something with the static. How to I combine (overlap) two pdf files into one page. Load both PDF files in Inkscape, adjust slightly if necessary so everything aligns, and export the resulting file to PDF. You can convert the PDF files to SVG before loading to Inkscape, if the Inkscape converter is not up to your standards. You can use media-gfx/pdf2svg for that. What I do nowadays (if I have a PDF to fill that has no forms), is to load the PDF in Inkscape, and fill it with the text tool. Then print it or export it to SVG or PDF if I want to keep it. Regards. What I'm looking for I think it is called stitching two pdf files. I use something like: use pdf2ps to covert the files to postscript use psjoin to stich them together use ps2pdf to get back to pdf psjoin is a script at http://homepage3.nifty.com/tsato/tools/psjoin.html BillK
Re: [gentoo-user] Calculating dependencies...: Any way to make it faster?
Am 24.01.2015 um 05:20 schrieb meino.cra...@gmx.de: Is there any way to make it faster or (in other words): Are there different ways to Calculating dependencies... and have only chossen the slowest one...? What can I do to spped it up? Portage is written in Python, normally running on CPython. While CPython is the standard, it isn't the fastest way to run Python. You could try switching over to PyPy, which uses a JIT-compiler that CPython doesn't have. This should get quite a big performance boost, if portage is being able to run under PyPy, that is. Alternatively you could try a portage replacement like Paludis, which is being written completely in C++.
Re: [gentoo-user] Re: Get off my lawn?
Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target.
[gentoo-user] Latest chromium-40 on ~x86
Hi folks, I've been using chromium successfully on my ~x86 system for quite a long time, but starting with the last two updates that came in during the last few days (namely, chromium-40.0.2214.85 and chromium-40.0.2214.91), I started having problems. Both of these versions build just fine, but upon trying to launch them, the browser's interface comes up just fine, but will only display a Something went wrong... page. I can try typing in and accessing URLs, but all I will ever get is this error page. That's not all, though, I also get to see error messages, namely the following in my terminal: ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0265 And this here in dmesg: chrome[5274]: segfault at e806109 ip b5c5c945 sp ac280980 error 6 in chrome[b1864000+5eed000] Great, I thought, something wrong with the sandbox stuff. So I tried to launch chromium without it (chromium --no-sandbox), and indeed: The browser works absolutely fine this way - I get none of the problems or messages mentioned above. Of course, I tried to find a related entry in both the Gentoo as well as the chromium bug trackers, but I couldn't find anything in either. I'm a bit reluctand to report my own bug as I wouldn't be 100% sure that I'm not causing the problem (after all, I'm building my chromium with USE=custom-cflags, which is not officially supported, but has always produced nicely working builds for me in the past), so I thought I'd ask here first if I'm the only one observing this behavior. The question, thus, would probably be: Anyone using one of the recent chromium-40 versions on ~x86 or anywhere else and seeing something similar? Or probably someone who has experienced something like that before and could offer a guess what might be wrong here - a real bug, custom-cflags, or something entirely different? Thank all of you in advance! Greetings, Nils
[gentoo-user] Failure with cfg-update:* invalid key... try again: bash: readkey: command not found
Hi, after submitting cfg-update -u I got * invalid key... try again: bash: readkey: command not found printed on the screen endlessly. How can I scuccessfully use cfg-update as before? What did I wrong? Best regards, Meino
Re: [gentoo-user] emerge default config
On Fri, 23 Jan 2015 18:30:52 -0500 Rich Freeman ri...@gentoo.org wrote: On Fri, Jan 23, 2015 at 5:45 PM, shawn wilson ag4ve...@gmail.com wrote: Is there a way to have default config lines that emerge updates won't touch? I'd be interested in hearing about alternatives, but I switched to cfg-update from dispatch-conf and such because it does automatic 3-way merging. It is pretty good about detecting stuff that you customized and auto-merging those lines as long as the upstream file doesn't change. If it does, then you get a 3-way merge in meld or another tool to do the merge. 95% of the time it just automerges all config file updates without any interaction. dispatch-conf does automatic 3-way merge too, I guess. At least it offers me pre-merged file (that I have modified) from time to time which I can just confirm (right there in the console). But somehow it does that less often than I think it could and most of the time offers me just diffs. Although it is not that bad since there is not much of them (it does lot of full automatic merges without even asking for confirmation), there are some files for which I get diffs over and over again. sshd_config is one of them, same as the OP. Robert -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
Re: [gentoo-user] Calculating dependencies...: Any way to make it faster?
If the bottleneck is reading the information from disk you might upgrade the SD card or use a USB drive instead, which may have better random access performance. You could also store the portage tree on another machine with faster storage and access it over the network. If the bottleneck is actually calculating the dependencies, you are probably out of luck for the immediate future. For calculating dependencies I suspect the larger bottleneck is reading everything from disk, seeing as the machines seem fast enough you didn't complain too much about actually compiling. In either case you should try to revisit distcc and cross compiling as that is the only reliable way to speed everything up. You do not necessarily need to use distcc with a cross compiler (the configuration most likely to cause problems, though the wiki does address this).
Re: [gentoo-user] Calculating dependencies...: Any way to make it faster?
On Saturday 24 January 2015 06:56:16 meino.cra...@gmx.de wrote: I experimented with kinds of not compiling it natively like distcc, crosscompiling and such. May be me of may be a problem with the tools/ the environment/the setup or whatever: The results were corrupted systems every time. This costed me even more time than waiting for Calculationg dpeendencies So I am back to natively compiling that stuff... Have you tried exporting your packages directory over NFS to a chroot on another box? I do this for my little Atom box and it works a treat; I know that at some others here do the same. You just have to make sure that /etc/portage/... files are identical between the two machines - apart from those few things you actually want to differ, like MAKEOPTS and buildpkg. Before discovering this method I tried distcc and cross-compiling and had nothing but pain, but the nfs-packages method is straightforward and easily understood. -- Rgds Peter.
Re: [gentoo-user] Calculating dependencies...: Any way to make it faster?
On Sat, 24 Jan 2015 07:03:30 +0100, Tomas Mozes wrote: Binary packages: http://thread.gmane.org/gmane.linux.gentoo.devel/94176 In my experience, using the -k or -K option makes emerge take longer to calculate the package list, which makes sense as it also needs to check the availability of packages. You could try a lower --backtrack value, but the time saved may be more than lost again when it causes problems. -- Neil Bothwick Hors d'oeuvres: 3 sandwiches cut into 40 pieces. pgp9OXirksYKp.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Failure with cfg-update:* invalid key... try again: bash: readkey: command not found
On Sat, Jan 24, 2015 at 3:34 AM, meino.cra...@gmx.de wrote: Hi, after submitting cfg-update -u I got * invalid key... try again: bash: readkey: command not found printed on the screen endlessly. How can I scuccessfully use cfg-update as before? What did I wrong? Update to cfg-update 1.8.9. Go figure, cfg-update was one of the few programs out there that actually used the functionality exploited by shellshock... -- Rich
Re: [gentoo-user] SMART drive test results, 2.0 for same drive as before.
Dale wrote: Howdy, This is concerning a hard drive I had issues with a while back. I been using it to do backups with as a test if nothing else. Anyway, it seems to have issues once again. SNIP Since this is the 2nd time for this specific drive, thoughts? By the way, I'm doing a dd to erase the drive just for giggles. Since it ain't blowing smoke, I may use it as a backup still, just to play with, until I can get another drive. I think that moved up the priority list a bit now. Thoughts? Dale :-) :-) Well, I have dd'd the thing a few times and ran the tests again, it still gives errors. What's odd, they seem to move around. Is there a bug crawling around in my drive?? lol # 1 Extended offlineCompleted: read failure 40% 21500 4032048552 #12 Extended offlineCompleted: read failure 40% 21406 4032272464 Anyway, I'm going to start saving up for a new drive. I may see if I can jump around that bad spot or something since right now, any backup is better than nothing at all. Well, sort of anyway. I'm just wondering if I should update to a 4TB drive instead of a 3TB one since I'm over half full already. :? /dev/mapper/Home2-Home2 2.7T 1.7T 1.1T 63% /home Thanks to Daniel and Bob for their replies. I think this drive needs a funeral. Once is bad enough but twice, not good. Dale :-) :-)
Re: [gentoo-user] Re: Get off my lawn?
Hello, Rich. On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote: On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer m...@marc-stuermer.de wrote: Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target. Do you regularly update the software on your embedded system? systemd-183 hasn't changed a bit since the day it was released. systemd-183's velocity is unchanged from the day it was released, and it isn't slow. The fast-moving target bit is only an issue if you want to keep updating it. Quite the contrary - the fast-moving bit is an issue if you _can't_ update it, or if updating is expensive, which is frequently the case for embedded systems. Fast-moving software is likelier to be buggy than well established traditional software. That said, systemd doesn't change THAT much between versions as far as the key interfaces go. But busybox changes even less. -- Rich -- Alan Mackenzie (Nuremberg, Germany).
