Re: [GTALUG] Securely wiping SSDs
If the data that will be stored on a new drive is confidential enough that a privacy leak would be Bad then the current standard of care would seem to be encryption so that if the media did go walkabout it would not be readable. If you’re going to reuse a device for a new project then losing the encryption pass phase and reformatting should suffice, with maybe one pass of zeros to be sure. And on disposal, the golden standard has always been physical destruction. I understand the Pentagon uses thermite for this purpose, but I have access to a pneumatic chisel and reshape the device with that. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Exim vs Postfix [was: Local-only mail server]
On 2023-12-24 11:49, D. Hugh Redelmeier via talk wrote: I used to use Sendmail but switched to Postfix some time this century. Why do you choose Exim instead? Is it just that Exim is the default on debian? A lot depends on which one you know how to drive. I've run Exim at a couple of jobs and know some of the experts online, so it's what I grab when I have to set one up. Note, I use a single config file the way the Exim community means for it to be done and nuke Debian's attempt at modularizing when that's the underlying OS. In the past I've had occasion to drive smail2, smail3, qm**l, sendmail, postfix, exim, and nullmailer over the course of being postmaster at a few places. Most of that I'm pleased not to have to revisit. (Note I blip the vowels from qm**l as was the custom on alt.sysadmin.recovery back in the day; a certain MTA author grepped his Usenet feed and would join any discussion that mentioned his work so it became one of the things not mentioned there.) (And apropos that newsgroup and MTAs, someone there had a formal curse: "May your sendmail.cf be edited in Notepad, only to be discovered on the next reboot".) Merry Christmas, everyone. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Local-only mail server
On 2023-12-22 14:44, Giles Orr via talk wrote: ... I find I have a lot of mail generated by cron and the like on several local machines, and I'd like to A) centralize that mail on a local server, and B) be able to view that with Thunderbird. Platform is Debian. It's not my intention to handle my Gmail or anything like that: this is meant exclusively for handling mail from local computers. Which would also mean the ability to send mail isn't important. Exim4 would be the right solution on whichever host you designate your mailserver. Enable listening on port 25 on your LAN, making absolutely sure spammers can't get at it, and disable relaying. Choose some local domain and tell exim to accept mail for that, and alias root and all the other usual system users to your own userid. Verify you get any mail it handles for root at local domain. (I use mutt directly on the mailserver, but setting up something like Courier IMAP to permit Thunderbird on your workstation to access your inbox should be somewhere near straightforward.) Then on the other hosts, apt install nullmailer and give it a config with the site's local domain to tack onto usernames and the hostname of your mailserver to which to punt the mail. You should see a test-o-gram arrive in your inbox, and if not both hosts should say something in their logs. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Meeting tonight?
> On Dec 17, 2023, at 12:44, Lennart Sorensen via talk wrote: > > Is there a meeting tonight given I think it is the second tuesday of > the month? Certainly seems to be Sunday today… > Wasn't sure if an annoucement was stuck in a queue somewhere waiting to > be permitted through. And it does appear that a great queue-unjamming has occurred. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] serial and parallel ports [was nice deal on ThinkPad E16]
On 8/2/23 03:31, D. Hugh Redelmeier via talk wrote: | From: Anthony de Boer via talk | The FTDI USB-Serial adapters were very good, but then the market got flooded | with cheap PL2303-based ones that are horrible, losing whole swathes of text | during fast screen updates. They're generally only okay for slow traffic. What does that mean exactly? The serial-to-USB dongles are not connected to the screen so "fast screen updates" isn't exactly a dongle function. Are you saying that they get over-run during fast or sustained transmission? That sounds like a driver problem. The usual situation was using the dongle in the serial port of a device that was about to start up and output several kilobytes of boot messages to its serial console at 57600 baud, using minicom in an xterm on my Linux workstation and the USB-Serial dongle to watch what was happening, and realizing chunks were missing from the story the device was trying to tell me. I think that if it was a driver problem our Linux community would have jumped on it, especially for something as ubiquitous as the PL2303, and when I looked into it the news was that it was a chip problem. Even in the old days, overrun was too easy with some serial input ports. Original UARTs were double buffered. 8250's like in the original PC had deeper buffers. If you don't have deeper buffers, you need the OS to have very quick real-time response to serial port interrupts. Old-timer stories -- feel free to ignore: My Kaypro II could handle 9600 terminal emulation only because I rewrote parts of the firmware (CP/M BIOS in EPROM) for faster screen output and wrote my own terminal emulator to use serial port interrupts. The NABU 1600 could handle 9600 serial input only because Sheila Crossey of HCR wrote some code in the UNIX kernel to handle serial input in a pseudo-DMA way. I think I've still got a Kaypro II somewhere because I just can't stand to e-waste such great engineering of yesteryear, especially after spending quality time with it back then. The closest I got to the serial ports was writing an xmodem for CP/M to try and juice a bit more transfer speed out of our hardware, and later porting that to early MSDOS. That would have been nearly the last assembler I wrote before gaining access to the new C compilers that were starting to appear. A bit later we had Unix servers with dozens of users on serial ports all talking to a single-core 386 or 68k and we thought these was a good systems. A big part of it was smart multi-port serial cards that handled "cooked-mode" line buffering for the users and only interrupted the OS when there was a whole line of input to process. That would have been mid-80s into the early 90s. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Favorite desktop manager?
On 7/31/23 09:32, Kevin Cozens via talk wrote: There is more than one way to pronounce MATE? Years ago, an Australian friend (anyone else remember Rob Chanter?) was discoursing on the varied pronunciations of that word, ranging from a drawn-out appreciative "mte" for the buddy who had just bought you a pint, to a very short and clipped "mate" for someone who was on the verge of being on the other side of a brawl. And it's the word for your coworkers and any other group you're with, a very all-purpose term in that culture with context encoded in pronunciation. And then there's the South American drink by that name, coming out of a totally different linguistic tradition. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] serial and parallel ports [was nice deal on ThinkPad E16]
On 8/1/23 00:02, D. Hugh Redelmeier via talk wrote: ... I guess that a USB-to-serial dongle would be OK. The FTDI USB-Serial adapters were very good, but then the market got flooded with cheap PL2303-based ones that are horrible, losing whole swathes of text during fast screen updates. They're generally only okay for slow traffic. I haven't had to buy another one in several years so haven't sampled the market recently. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Red Hat Paywall...
On 2023-07-05 08:57, Giles Orr via talk wrote: ... Makes sense in a depressing way: Debian wants a _stable_ version for stable, and testing is for testing things that will become the stable distro ... Huh - testing is called "trixie." I always wonder which toy is coming next ... Debian testing runs in a cycle with their releases. Just after the preceding one (bookworm) came out, it opened to a lot of heavy-lifting upgrades and you're more likely to see glitches. Then they start calling code freezes and stabilize things when they get closer to releasing the next one (trixie) in about two years and you'll see fine-tuning of bugs in the pre-release era and testing will be a lot more stable for any innocent users, then comes the grand release announcement and the next new cycle. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Anybody using rclone?
On 2023-06-04 09:48, Lennart Sorensen via talk wrote: Personally I use rshapshot for backups with a target being a linux server at my parents house and then they backup to mine the same way. No cloud providers, nothing complicated, it just works and it's automatically offsite. Of course it's great for making a backup of your data, it is not for making a system backup should you need to restore the system, but I don't consider that to my a big task in general. I also tend to use at least RAID1. I found that rsnapshot does a lot of filesystem churn on the target system, which can start to be an issue with data that has a huge number of small files that wanted hourly snapshots all hitting RAID6. It will do an rm -rf of older snapshots, resulting in each directory having to be cleaned out entry-by-entry, all the files having their link counts decremented, lots and lots of inode activity, and then it builds new snapshots and has to increment link counts and build new directories. The solution I found was to recycle older snapshots, letting rsync bring a recently-retired snapshot up to date making only the new changes before calling that the current snapshot. For absolutely vital data there's also a lot to be said for keeping it in a git repo to track changes and being able to revert damage, and then git push of a packfile can be your backup. There's still a lot to be said for tarball backups, since they hit backup target storage as a single coherent file and don't do the disk thrashing. Nowadays something in a squashfs image could let you mount that and copy out individual files without having to restore the whole tarball, so that's an interesting direction too. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] war story: gtalug.org's filled up
On 2023-04-05 15:34, o1bigtenor via talk wrote: On Wed, Apr 5, 2023 at 12:23 PM Kevin Cozens via talk wrote: ... To avoid the problem in the future I always have servers running logwatch. It gives me a daily report of system activity based on various log files. Of particular relevance to the topic of this message thread is the bit near the bottom. It reports on in use and available disk space. ... Daily reports getting mailed to you can have a problem that they're long and repetitive and get ignored after the novelty of reading them wears off. So long as they're concise and to the point and focus on anomalies and don't go listing all the normal things and you actually read them they can be ok. And some issues can go from zero to major problem in less than a 24-hour cycle so an alert sooner can help. Quite a number of years ago a now deceased mentor advised that a great way to reduce the problem caused by a runaway var file was to use separate /var and /usr partitions (from / and /home). (Not sure Thunderbird is getting the quotation levels right here, but the first bit was Kevin and this bit was o1bigtenor. Getting homesick for Mutt.) The filesystem root and /usr are static, so they only care at upgrade time that there's enough space then, and at other times will happily sail past filesystem-full events. Separation mostly makes sense if you want one thing to still work when another thing fills its partition, eg being able to write /var/log even though the dear users have filled /home or /tmp again. And nowadays /tmp is usually its own tmpfs already. Monitoring disk space and being proactive before usage hits the roof is a good thing for those of us who value tranquillity and hate having to deal with things like this at inconvenient times or after the users notice. But a long-ago coworker once said "We've got to be reactive, not proactive" because we were in an environment where you got brownie points for heroically responding to disk-full tickets, but if you kept things running smoothly you'd be looking at layoff papers. (In other news, I'm no longer there.) Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] war story: gtalug.org's filled up
On 2023-04-04 17:50, D. Hugh Redelmeier via talk wrote: Violence is sometimes the answer. Now we see the violence inherent in the sysadmin! sudo apt clean That left only 32% of / used. Note /var/cache/apt/archives is only a cache. If the system wants any of these, it should be able to find them in a repo. More recent Debian seems to have made automatic cleanup the default. Is this something older or more Ubuntu-like? And really it makes little sense to keep a .deb you're only going to install once! Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] rejuvinating an old machine: inexpensive SSD
On 2023-01-02 23:45, D. Hugh Redelmeier via talk wrote: ... If you want a really good SSD, you want one with DRAM. Unfortunately they seem to be quite a bit more expensive. A 500G Crucial MX500 is $69.99 at Canada Computers (much worse on Amazon.ca). The 1TB MX500 is 101.50 at Amazon.ca. Why would they add DRAM to the SSD itself? Buffering writes so it can report success sooner? What if you have a crash or shutdown before the flash write actually happens? This sounds like a misfeature designed to beat benchmarks. Back in the Unix days the rule of thumb said that adding more RAM to a system was the most effective way of improving performance. I believe that's still true and maxing out the system DRAM on your Linux box's motherboard remains high on the list of things to do to get more out of the system. BTW, crying over those prices sounds like 21st century first-world problems, considering the princely ransoms we paid for wee fractions of that much storage back in the day, or being in awe of the first sysadmin on Usenet who was running a Terabyte Array in their datacentre. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Making RPM from directory tree?
On 2022-06-11 6:09 p.m., William Park via talk wrote: To RPM guys, I have a directory tree, created from "make install DESTDIR=...". Now, I want to make RPM package from the tree. Online docs are too verbose and confusing. 1. Is there GUI app with appropriate fill in boxes? 2. Is there command line utility? In Slackware, it's just "makepkg". You need a "spec" file, which is a single formatted file giving the recipe for building the package for that system. There's a command line utility called "vi" that I've found very helpful when I've had to construct these files. Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] From Slackware to which distro?
On 2022-04-27 12:37 a.m., William Park via talk wrote: Hi All, I've been running Slackware since forever. It's time to grow up and see the world. Which distro would you recommend that I move to? Yes, I know it's personal, and reasons will be varied and educational. - Ubuntu -- OK. I use it at work in VM and in WSL (Windows Subsystem for Linux). For me, Mint is another flavour, just like Kubuntu, Xubuntu, etc. It can make a lot of sense to run the same at home that you use at work, so that you're only tracking one distro's quirks and issues, and being that much more effective at work and needing that much less time spent debugging issues at home. I was running Red Hat back when a past job was on that, up until Red Hat jumped the shark, then CentOS during a couple of gigs that used that, then I decided it was time to dig into Debian just months before a job that used that came over the horizon. So now most of my boxes run Debian. Meanwhile I picked up Gentoo back around the time RH was bothering me too much to touch on my own time anymore, partly as a technical challenge to myself and partly to have the actual source code to everything actually downloaded, but that can suck up an awful lot of time even as it hones your sysadmin skills! Anthony --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] I'm discarding an old notebook!
D. Hugh Redelmeier via talk wrote: > ... > Other than that, the machine is functional. I have an even older notebook with a 32-bit Atom processor. It used to be useful, but after upgrading to the latest (Debian Bullseye) Firefox barely starts and is glacial enough to be totally unusable. Older Firefox did run reasonably on that hardware, but software keeps assuming better hardware as it grows. There may be roles like serial console or network debugger for a box like that. Or stick with an older Linux contemporary to the hardware; sometimes bits of old software need an older libc or such and it can be handy to have a retro-system in reach. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Kurzweil Reading Edge
Lennart Sorensen via talk wrote: > Well youtube-dl still works fine whenever I use it, so that should still > be fine. ... You'd be on Debian Sid as I recall. Likewise it's good on Gentoo, but youtube-dl needs to be fairly up-to-date as the underlying Youtube service and the tool change frequently, so you need to be on a forward-leaning distro. It's not going to do as well on Debian stable or anything like that. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Has the graphics-card world gone mad?
Lennart Sorensen wrote: > On Tue, Mar 30, 2021 at 01:08:53PM -0400, Anthony de Boer via talk wrote: > > If all else fails, a Raspberry Pi 4 will drive a pair of high-end > > monitors, probably not with the grunt that any modern game would want, > > but enough to be the new X Terminal. > > It can drive one 4K screen at 60Hz. It can drive two 4K screens at 30Hz, > which I sure wouldn't want to use. It rather ruins video playback in > many cases. Some of us are more into a few lovely huge xterms for hacking on code, maybe SSH sessions somewhere or a browser or MUA and such, a bit of Bach happening on the audio output, and not so much into games and video and the overwhelming-bandwidth experience. (At one point my son was looking at the price of some decent hardware for running flight sim, and found he could have quite a few hours wet rental of a Cessna 152 for that money; the latter won out. I'm of the same opinion; get up from the keyboard and experience real life rather than trying to simulate it on the computer.) -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Has the graphics-card world gone mad?
Giles Orr wrote: > On Tue, 30 Mar 2021 at 13:08, Anthony de Boer via talk > wrote: > > ... > > If all else fails, a Raspberry Pi 4 will drive a pair of high-end > > monitors, probably not with the grunt that any modern game would want, > > but enough to be the new X Terminal. > > That just shifts the problem. He has a good computer with a > not-entirely-working video card. You're suggesting something that > would put him in a situation where he'd have a passable video card > with a not-entirely-working computer attached to it. At no point did I suggest this would outperform anything, other than a lack of a usable video card on the good computer vs the Pi being able to light lots'n'lots of pixels. Back in the day it used to be customary to run X applications on the big grunty server in the machine room, talking over the network to a relatively underpowered desktop X Terminal that knew little more than how to paint stuff on the screen, and that's still a possible fallback today, with the big PC using the RPi as a terminal. Awesome PC video card > RPi4 > crappy or no video at all. > Don't get me wrong: I use Raspberry Pis for a lot of things. But I > don't use them as my daily driver, because they don't have the > horsepower. Shifting to ARM would also break most games. They're more powerful than most of the machines us oldtimers have used, not an entirely bad modest desktop experience in their own right, and a possible silent-computer frontend to noisy spinning rust in another room. Granted, the ancient X protocol didn't include sound and this is probably going to be a much more viable setup for a non-gamer. But back then we had 10 Mbit thinnet shared with everyone else on the floor, while nowadays we have to make do with GigE, so the experience might actually be better than remembered. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Has the graphics-card world gone mad?
Evan Leibovitch via talk wrote: > I have two 4K screens (Samsung U28E590D) that I want to use in day to day > work. Maybe some streaming, but the most intensive game I would play is > Cities: Skylines > Any suggestions on what is the minimum GPU that will reasonably drive them? > I've backordered a GTX 1660 at $315. Would a 1650 Super be enough? If all else fails, a Raspberry Pi 4 will drive a pair of high-end monitors, probably not with the grunt that any modern game would want, but enough to be the new X Terminal. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] interesting article on FreeBSD kernel almost getty dangerous code
Lennart Sorensen via talk wrote: > On Mon, Mar 29, 2021 at 04:10:38PM -0400, Peter King via talk wrote: > > OpenBSD is still thriving, and they carefully audit all their code before > > incorporating it, as well as have ongoing rolling security audits. They > > may be too extreme in their focus, but that's another issue. > > Oh OpenBSD definitely handles code updates in a safer way than FreeBSD, > although it seems their rate of progress may be even lower then FreeBSD > and not too much is happening there. One thing all the *ixen are facing would be all the niche hardware that not every developer has, and can test or code for. I really think that drivers ought to be sandboxed like user processes so they can interact with their hardware only, and their code crashing can't bring down the whole kernel. And maybe canned drivers could be a bit more portable too. There'd still be the license barrier to hurdle between the Linux and BSD camps, but a driver that was arms-length from the kernel itself might be at sufficient distance for that too. Back when I was working with OpenBSD I found that it was too much about network security and it was near-impossible to do a simple RAID to protect my data from threats coming up from the hardware. > And I doubt any of the BSDs will ever have a userspace that is worth > putting up with. Last time I ran a BSD desktop (bunchteen years ago) it was the same X environment that I had over on my Linux box. At one point it was where you had to go for ZFS and for jails (chroots with network namespacing) and then awhile later Linux got ZoL and LXC that looked suspiciously familiar. Other stuff like FUSE has been ported the other way. But I think folk develop expectations of what's in a modern *ix and the feature set tends to converge back and forth. Between Red Hat and Gentoo and Debian and FreeBSD I'd always find the great majority of packages I wanted in their respective packaging systems, and every one of them had at least one moment of being sworn at for omitting something I should have found them carrying. The range of Linux distros and BSDs tend to be more similar if you're looking for a generic traditional portable OS, but the latest new features always require picking up one that has that (or doing like a hockey fan of a different team and downplaying the need for the feature until your side has it!) -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] David Tilbrook
Russell Reiter via talk wrote: > On Saturday, 16 January 2021, D. Hugh Redelmeier via talk > wrote: > > > David Tilbrook passed away in the night yesterday. COVID-19, dammit. Requiscat in pace. > > David had given a couple of talks at GTALUG. > > I attended one of those talks where he introduced his QEF toolset and > software hygiene concepts. Quod Erat Faciendum, with the metaphorical > subtext, washing behind your ears. At a long-ago TLUG meeting, the arranged speaker was a no-show but then in walked David with his laptop slung over a shoulder, and Drew asked if he had a talk he could give. A few moments later with the projector hooked up, he selected the slides from a talk he had given 20 years previously on making software portable between Unix and VMS. He pointed out that if you crossed out Unix and wrote in Linux, and likewise VMS became NT, then absolutely nothing had changed and the talk was still fresh when he delivered it that evening. I also have to remember a post-meeting beer gathering one summer evening just after Edsger W Dijkstra had passed and David was recounting good times they'd spent together. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] The Best of GTALUG
Warren McPherson via talk wrote: > What was a moment for you of GTALUG at it's best? Way back when an actual published book about Linux was a totally new concept, O'Reilly sent Matt Welsh on a book tour to support "Running Linux" and there was a tour stop in Toronto. I was sitting in the second row just behind Drew Sullivan. Matt started describing the then-latest features in Linux, including its ability to run SCO Unix binaries. Drew started to correct various technical points, exasperating Matt to the point he stopped and exclaimed "_I_ wrote the book!" to which Drew replied "Yes, but I wrote the kernel code". And I'd be remiss to not mention the otherwise-totally-forgettable computer show downtown that had gotten Linus Torvalds to fly to Toronto. TLUG (as we were then called) presented him with a TLUG hockey jersey with a big "1" on the back. There was a beer reception afterward. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Group knowledge base
Michael Galea via talk wrote: > I have never had a problem administering dokuwiki other than the usual > installation wrinkles. And the fact that the content is stored in > plaintext files makes it easier for me to backup (and gives me some > assurance that I have a way out of it if I want). I've had good experience with ikiwiki. It keeps the wikitext in a git repository and renders to HTML on the server as-needed, so I can fetch the repo and work in the plain wikitext with grep and vi and the usual tools, then push a commit to the server and it updates the HTML view. Or I can use it like a normal wiki and edit in the browser. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Apache fails after upgrade
William Witteman via talk wrote: > > On Thu, Oct 08, 2020 at 10:34:12AM -0400, Lennart Sorensen via talk wrote: > > > That kernel is your problem. That in no way has any business being > > > on debian testing. Current Debian stable uses 4.19. Previous stable > > > was 4.9. 3.16 is from at least 5 years ago and certainly is missing a > > > ton of features required by any system these days. > > ... > > linux-image-amd64 is already the newest version (5.8.10-1). What's the uptime like on that system? Going past two kilodays is possible; I've done it. But you end up with a seriously ancient kernel underpinning the system. Rebooting once a year or so is probably reasonable. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] sale today on ThnkPad T490 and tiny ThinkCentre PCs
Lennart Sorensen via talk wrote: > I guess Lenovo is clearing out the T490s given the T14 is the current > model. I have no idea why they only offer AMD Ryzen in 14" T series, > and intel only for the 15". It could be that they positioned two models "diagonally" from each other for people who want a specific CPU brand or exact screen size, so they could satisfy four possible choices with only two models. But much more likely they're already cleaned out of whatever other models they had. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Laptop recommendations?
Lennart Sorensen via talk wrote: > I wonder if the developers had competitions on who could write the > shortest working loader program. No fair modifying hardware to create the new instructions you needed. That was a thing, back when it was still possible to get tools between parts of your CPU. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Laptop recommendations?
El Fontanero via talk wrote: > Why, we'd 'a given our eye teeth for PCMCIA! In *my* > day... Back in the day a REAL card went 9 Edge First, and you'd best remember to dump out the chad hopper after punching your program. I think I still have a FORTRAN deck I did back when. Meanwhile, addressing the old-media-compatibility issue, having USB dongles that do the job is probably[0] the third best thing, second best is keeping an old system[1] around that still has the relevant readers[2], and the best is to have dubbed all your old media to newer storage during the era both were current so you'd not have to worry about whether you can get one more gasp out of the corpse of dead technology. For a laptop, portability, usability, and not being so stinking expensive you're afraid to take it anywhere are key attributes. Being able to leave most of your bag of tricks at home or in the car or in the laptop bag can really save weight and clutter. [0] those are never quite the same as the classic hardware they replace. [1] eventually ancient hardware supported in an earlier Linux will be forgotten by newer kernels; a software upgrade on your designated dinosaur can too easily be what kills it. [2] optical drive or some of the three sizes of floppy[3] drive. [3] formats were never quite the same; who else remembers the story of how Apple ][ floppies were written and read based on 6502 clock cycles of the I/O loop, or ran the disassembler deep enough to comprehend the true horror of how CP/M on that platform did its disk functions? -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] [GTALUG-Announce] GTALUG: COVID-19 Impact
Lennart Sorensen via talk wrote: > On Mon, Mar 30, 2020 at 03:11:29PM -0400, Alvin Starr via talk wrote: > > If the call initiator mixes all the data for all the participants its not > > really distributed. ... > > jami certainly claims to be peer-to-peer and even claims to have less > latency because everyone sends directly to everyone else. Might be interesting to do some traffic analysis and find out what it actually does. Most folk are behind a NAT device of some description or other, purporting to only allow outbound connections. But it turns out that if at least one end is behind a really cheap NAT device, it's possible to trick it into thinking an inbound connection is outbound and get a session going. See Wikipedia on NAT Traversal and Hole Punching. Linux and BSD NAT implementations are too smart to fall for this, though, and denizens of this list might just have a leaning toward Linux devices. There's a chance it would fall back to going via a public server if it can't open traversal between a pair of endpoints. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] How much do you know about how linux executes binaries?
Sergio Durigan Junior via talk wrote: > ... > BTW, Debian offers busybox-static to help with this kind of scenario. The problem is that you have to already have that installed before that kind of oops, and it has to be just that kind of oops, ie not something minor that doesn't need that kind of tool, nor something major that calls for a complete reinstall/restore because on a clear disk you can seek forever. Back in the day when Unix was a complete PITA to install that kind of heroic effort was something sysadmins aspired to, but especially with test instances and virtual machines nowadays it's almost always easier to just roll a fresh one. Granted, if you have root on both it can be too easy to pull a trigger on your workstation or server rather than the test instance you meant to test so it's good to see that those skills haven't died out of the world and are still exercised in 2019. Pro tip from back in the day was to always resist the urge to hit reboot, because a partially-hosed machine that still had a root shell open or such gave you a state you might not be able to boot back to. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Hardcore sed foo
Dave Collier-Brown via talk wrote: > On 2019-11-08 11:41 a.m., Giles Orr via talk wrote: > > Eyeballing simple regex is hard enough, but mentally parsing out a > > complex full line regex that looks like inline garbage without the > > benefit of comments isn't something I recommend or appreciate. > > An early boss described it as "programming in line noise". I've seen too many cases where the comments explaining what a block of code did were *wrong*, and debugging took far too long due to coders reading, trusting, or simply being distracted by this alternate theory of what the code was doing. Being able to read the code itself and figure out what it's doing is a primary programmer skill, and writing code that's not harder to figure out than it needs to be is important too. With regexen for eg matching logfile lines, a comment with a few different example lines that should match can be very helpful. Some explanation of *why* you're going to the trouble of doing something, or a simple explanation of what task a block of code encapsulates, are useful things for a comment block. But line-by-line attempts at translating code to English are counterproductive. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Hardcore sed foo
Lennart Sorensen via talk wrote: > On Tue, Nov 05, 2019 at 06:42:44AM -0500, Giles Orr via talk wrote: > > ... > > Jeez regex is a pain - it took three minutes of staring at that just to > > figure it out, even though I knew what we were both trying to achieve. > > Practice time! > > https://regexcrossword.com Oooh, fun! The Hamlet puzzle took a few minutes to sort out. But then I'm not a regular crossworder. One of the guys I work with claims that any use of regexen requires multiple lines of comment to explain, but I'm firmly of the opinion that being able to sight-read them is a basic Unix programming skill. -- Anthony de Boer --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Microsoft open sources Windows Calculator
James Knott via talk wrote: > I've only come across one editor that was worse than EDLIN. It was the > line editor on Pr1me computers. We had a few of those systems at work. > As I recall, you could only jump to the top or bottom of the file or use > relative jumps. You couldn't jump directly to a specific line. =-O Ahhh yes. That editor, on a Decwriter II, back in the olden days. Didn't know things were supposed to be better than that, so happily edited FORTRAN IV and PMA source with it and moved a lot of fanfold paper to the recycling bin afterward. Didn't find it all that lacking, for the era, but Unix ed was a step up, and vi was amazing (at least once I got on top of terminfo and could get it working on all the different systems I was supporting back then). We also had some Decwriter IVs way back then, and a genuine ASR33 with the ^G bell being an actual bell with an electromagnetic hammer, and some early glass TTYs at least one of which dated back to before the ASCII standard was finalized, so it had a left-arrow character in place of the underscore. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] What good is GIT's "index"?
D. Hugh Redelmeier via talk wrote: > In my workflow, the index is almost always identical to the > repository. I almost never use "git add" (which affects the index but > not the repo). I almost always use "git commit -a" which updates both > the index and the repo at the same time. The index is effectively the working candidate version of the project that will be the next commit. Doing "git commit -a" runs past that at high speed, going straight from the working tree via the index into a commit in the repository, so you're not really using it. The other workflows, with intermediate versions of a further-changed file in the index, or selected changes staged there, or as resolving-ground[0] of a nasty merge conflict, make more use of the index. It does involve storing all your new files in the repository; the index then records the OID of each, along with the mtime etc of the files in your working tree, which helps git very rapidly scan your working tree and tell you what is or isn't added. Other than that you could almost think of it as a candidate-tree OID for the next commit. Git is a collection of tools to cover just about everyone's different workflow, so there are a lot of bits that we're not all expected to use, or that might be extra moving pieces to get in our way. Sometimes it's not until you have a particular issue to crack, or have multiple developers committing to the same project at the same time, or have to comply with some maintainer's repo policy, that the use of a particular tool suddenly makes sense. [0] Why would it be that after some decades of Unix, I can't spell "resolving" without stopping at the "v"? -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Backups with Bacula
Giles Orr via talk wrote: > And I have to disagree with Anthony on this one: spinning disks are going > to be in use for a while as external backups: sure, they're slow, but this > is a BACKUP. Cost per terabyte is immensely lower and speed isn't usually > the priority, and you can put multiple copies of backups (or diffs, or > whatever suits you) on one large external. Certainly you're going to use spinning rust for multi-terabyte backup sets, but the point I was getting at is that if that's your archival set whose files are set in stone once written then you may only need to do backups of that monthly or less often, while a small active fileset (including any recent archival additions) may be in the tens or hundreds of gigabytes range so that your dailies are small and manageable and have a good chance fitting onto flash. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Backups with Bacula
Lennart Sorensen via talk wrote: > My experience some years ago with 3 USB harddrives that were rotated > weekly was that the disks didn't last long. 3.5" HDs do not like > being moved a lot and frequently died. Moving to tape was way way > more reliable but certainly had a higher cost in terms of getting a > tape drive and for recovery you might need another tape drive while a > USB drive works with anything. You tend to only need spinning rust nowadays for the largest datasets, and I find that splitting archival from active filesystems helps. The archival stuff tends to be huge but write-only: media files and tarballs and such get written and then left as-is for the life of the filesystem. That requires a much-less-frequent backup! And that reduces the size of the active filesystem plus any new archival files to the point it has a chance of fitting onto flash. Another way the world has changed is that sites are no longer such islands connected by 56k modems and sneakernet; there's more chance of being able to push a backup over fibre somewhere to a harddrive that's already offsite and doesn't need to be moved further. Having another datacentre to rsync to is ideal, as I'm not sure how much you can trust third-party "cloud" solutions. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] dreamhost reply, is dh key exchange question.
Jason Shaw via talk wrote: > On Wed, Oct 10, 2018 at 3:06 PM Mike via talk wrote: > > That is, SSH to your other shell account, and instead of running your > > email program, run "ssh user@eugene...", and once connected to eugene, > > proceed as though you were connected directly. > > This is a great recommendation and can be easily automated. In your > personal ssh config, usually ~/.ssh/config you can add in: > > Host *.dreamhost.com > ProxyCommand ssh -q shellworld_host nc %h %p Those suggestions are two very different things. Mike is suggesting SSH'ing to the shell on the intermediate box and then SSH'ing from it, while Jason is suggesting to SSH the intermediate and then use it to pipe an inner SSH connection through the outer SSH connection and emerge there for the onward hop to the destination. Caveat for the first solution: it involves using your credentials on the intermediate box, so if anyone evil has compromised it they can now pop the destination box too. Caveat for the second solution: the SSH conversation still involves the near-end client negotiating crypto with the far-end server, so if that started off being the problem it's still that problem. Also, the middle box might not have nc (netcat) installed but there are other tactics like LocalForward configuration that can do the same thing. > > Such plumbing is often necessary for a variety of reasons. Just make > > sure you know where you are. The commands "whoami", and "hostname" > > are often useful! Setting the bash prompt to include the hostname is helpful. Always pause a moment to be sure where you are before typing commands like reboot, poweroff, and such. I've even known people to alias away commands like that on shared servers after inadvertently using them a time too many thinking they were on their test rig. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] fail2ban problem
Michael Galea via talk wrote: > I am experiencing what I believe is a DNS amplification attack on my > bind9 DNS server. > > I'm seeing very of the following on different IPs > 20:11:53.977254 IP 108.234.250.76.62926 > 69.265.222.253.53: 50679+ > [1au] ANY? USADF.GOV. (38) > > My server responds > 20:11:53.96 IP 69.265.222.253.53 > 108.234.250.76.62926: 50679 > Refused- 0/0/1 (38) > > I imagine the IPs are spoofed. I agree with the diagnosis, but IMHO it might be better to configure your nameserver not to respond at all to such queries, especially as anything you emit at all is likely going to a victim of an attack. Internet-exposed DNS servers should really only respond to queries in domains for which they're authoritive. Recursive servers should be kept private enough to respond only to their local users. Disclaimer: it's been years since I ran nameservers for a midsized ISP and had to be on top of all this. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] System Monitor / sysmon
D. Hugh Redelmeier via talk wrote: > Do you have any suggestions for a simple (possibly simplistic) tool to > show disk bottlenecks in real time? I generally fire up "iotop -ko" when I'm tracking anything I/O-bound. Other friends are htop and iftop. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Thermal paste availability / Raising the dead
Alex Beamish via talk wrote: > There are, however, still a few files on the dead system I'd like to get. > Today I took that system apart, popped the fan off the CPU, and found dried > thermal paste. Hmm. A better bet if you're just trying to recover files is to get an appropriate USB external enclosure for the old system's storage device, put them together, and plug into your new system for review and copying. If the old system still has life in it, it should be attempting to boot from cold start and getting at least a bit of the way down the road before overheating and refusing to continue; in that case fresh thermal grease might work wonders. Blow dust bunnies out of the CPU and PSU fans and watch that they both spin; replace if not. But there's a good chance the old box is pining for the fjords. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] debian Linux -- Installation DVDs Full Set - Shipped To Canadian Destination ??
Steve Petrie, P.Eng. via talk wrote: > I'm looking for a source for full set of physical debian Linux (LXDE) > installation DVDs (NOT a live install, as I understand that Linux does not > yet support live install with UEFI). Note that they've gone to some effort to pack the stuff you're most likely to need onto the first DVD (or onto the full-CD image to a much-more-heavily-trimmed extent), so you should be able to get going with only that. The later discs are likely to go unused, or lightly used. If you're on a low-bandwidth connection, then a server running a caching proxy like apt-cacher-ng or squid can be your friend. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] life expectancy of 32-bit x86 [was Re: Fedora Netinstall] [long]
D. Hugh Redelmeier via talk wrote: > ... > So: I don't expect that we're going to see many programs that will > stop supporting 32-bit. A greater risk is that 32-bit ports will > become less tested. That may reduce reliability. > > Some distros are surely going to drop 32-bit soon. I would imagine > that debian won't be one of them. Debian has already dropped 32-bit PowerPC as a release architecture; 64-bit is still supported. And I've heard mutterings that i386 is getting too long in the tooth and that amd64 is very much the core architecture today. We're already seeing browsers needing ginormous address space and not playing nicely on smaller computers with less than four gig in which to romp. I'm expecting that 64-bit processors are going to become increasingly less optional in the desktop and server space, and that there may be a fork at some point with the full distros focussing on 64-bit and embedded distros being the thing to use on 32-bit hardware. 64-bit ARM has been awfully slow off the mark but is likely to be a big thing once it gets properly going. The only reasonable thing I've seen actually for sale and have personally touched and run is the Solidrun Macchiatobin. Decent little board, supports a proper DIMM-load of RAM, the 10gig SFP slots are overkill for most of us but it has a normal GigE port too. I haven't tried video but I've heard reports of people having luck with a card of the appropriate PCI flavour. (Technically you can boot arm64 on some Raspberry Pis, but they don't have enough RAM to make that worth trying.) -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] From BTRFS to what?
Alvin Starr via talk wrote: > On 09/05/2017 09:42 AM, Christopher Browne via talk wrote: > > ... > > They were fairly keen not to respond to *anything* because we had JFS > > (that they chose to include, but not support). That seemed really > > weaselly to me at the time. It would be one thing had we had a custom > > compiled kernel with our own wacky stuff, but everything *was* stock; > > the JFS builds were *provided by Red Hat*. > > > > Ever since, I have not been highly enthralled by the merits of "Red > > Hat support." > That is kind of weaselly but in line with just about every other > enterprise support organization out there. > First update to the latest software(images of the tape player in the IT > Croud). > Oh your using something we don't support Sorry... Linux supports more different filesystems than any other OS in history, but for the most part a filesystem's a filesystem; you toss in your files and have high expectations of finding them again later. And in the general Linux world you get to pick one, and see how well it works and whether its developers are on top of any bugs. However, when you get to Red Hat's paid support model, having to train support staff on the different tools to make and fix N different filesystems and the bits of wisdom that pertain to each will drive its costs up, and they can save a fair bit by pushing RH systems into a very limited subset of filesystems with solid track records and only having to support those. It's also possible they see ZFS-on-Linux as more powerful, or saw some unexploded Oracle intellectual-property issues under Btrfs and wanted to quietly back away. > But I moved from Debian to RH years ago because I was spending all my > time patching kernels and rebuilding systems. > Redhat had quick security fixes and they were easy to install. > This is something like 15 years ago and the landscape has changed > dramatically since then. > > The thing about RH is that its an easy sell corporately. > You can point to a company that "supports" the OS and check off that box > in the "due diligence" form. And if you're in the "Enterprise" model of wanting to buy an off-the-shelf system and support and not maintain any in-house clue then RH will happily take your money and dance that dance with you. > Debian and Ubuntu don't seem to have the same support offerings but I > could be wrong on that point. Debian at least is a volunteer organization and you can't wave the corporate Amex at them. They're generally quite reasonable at issuing fixes to CVE issues and their stuff Just Works but if you want to be spoon-fed you have to pick up the spoon in your own hand, as it were. > > - It enacts "facts" like those that were the point of the original > > question... Is BTRFS any good? Should you use it? Or is it needful > > to migrate to something else? The answers that seem to arrive have > > the shape "Well, RHAT doesn't want to support it, so everyone should > > consider it obsolete and unsupportable." I hope nobody is looking at redoing their root filesystems in any sort of stampede to a different filesystem. The choice of filesystem usually runs for the lifetime of an install, and when Btrfs became ready for prime-time I used it in a few non-core systems I was setting up, and it's been happily working. Certainly I'd not now try to swim upstream by using it on an RH/CentOS installation, but Debian and Gentoo are still happy with it. But the vast majority of Linux systems I've built have had ext2/3/4. (Mind you, a few Reiserfs systems a late co-worker set up _did_ get repaved proactively after one or two shat themselves. But that's the only FS that I've seen being actively bad.) I should add that the most solid thing I've used was ZFS, but that was on another OS; I haven't had occasion to look hard at ZoL yet. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Windows 10 will let everyone run Linux inside Windows following Fall Creators Update - TechRepublic
Lennart Sorensen via talk wrote: > Remember when Linux had a layer to run x86 BSD binaries? Now freebsd > can run linux binaries instead. I think it was called iBCS back in > the day. It was, and led to TLUG's finest moment, way back when Linux was new and there was only one book about it and O'Reilly sent the author (Matt Welsh, IIRC) on the speech circuit. He was standing up in Toronto and got to iBCS and how you could use a Linux system to run all your commercial Unix binaries and someone in the front row kept interrupting with minor corrections. Finally Matt got fed up and declared "_I_ wrote the book" to which Drew Sullivan replied, "And I wrote the kernel code!" -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Desktop swap
Evan Leibovitch via talk wrote: > For about the mid-nineties to the late aughts, I was a heavy-duty KDE fan. > The integration and customization was what I needed, it was good looking > and functional. > > Then it started getting more bloated and slower, seemingly outpacing the > increases in CPU speed and decreases in RAM cost. ... Back about 25 years ago when I was first in a position to run X (xterminal on my desk against one of the Unix servers at Geac), Drew Sullivan gave me a copy of his .fvwmrc (which was already several years old at that point) to get me started. That's survived bunchteen system upgrades (including the advent of fvwm2) and me periodically poking at it to add things like an MP3 play/pause hotkey. Still exactly the same RGB values for active-window and inactive-window, though. The really nice thing is that all the increases in system speed have played to my advantage rather than some software-bloatmeister's, and I've gotten away with still running shockingly-underpowered hardware (this netbook has only 128 times as much RAM as my first *ix system, so only about 1/16th what one would want as a minimum buying a computer today). So I recommend fvwm, lightweight configs, and not constantly leaping on the latest thing and losing all your finger macros. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Linux hardening question
Lennart Sorensen wrote: > On Wed, Jun 28, 2017 at 07:21:55PM -0400, Anthony de Boer via talk wrote: > > Many years ago a coworker tried "chmod 700" on /etc etc, and chmod 600 on > > many key files, the upshot of which was that everything on the "secured" > > firewall had to run as root and it ended up less secure. > > And 711 is no better. 744 might work OK though. You mean "OK" in the "OK if you want to really torque nonroot users off" sense, right? Just for fun, try "chmod 744 /etc" in a root shell, then "ls -la /etc" from a nonroot shell. Then change it back to 755 and deal with any other users wondering why the machine did a weird there. (For extra points, do this on a nonshared machine!) Things like ls get really confused if they can see that the files are there but can't even stat them let alone any other access. Users staring at all that STDERR don't fare much better. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] BOOST moved into a IDE using APT-Get
Dan K via talk wrote: > The official BOOST site has a bit of disparaging dialog on repackaging > efforts of various sorts. I think if your target system is x86, then > apt-get is probably a fine choice. But if you have to either x-compile, or > worry about updates, or want to enable non specific improvements in the > indefinite future of any calling app, the the hard way is the easy way ! You can apt-get stuff onto all manner of different architectures with no problem; Debian-style packages are built for quite a range. And the philosophy there (and with most desktop/server-ish Linux distros) is that software is compiled on its native architecture, so the source code gets farmed out to a hodgepodge of different boxes to compile for ARM, MIPS, PowerPC, and whatever else they want to support. Five years ago a bunch of us on this list visited Seneca/York for the launch of Fedora-for-ARM and saw the equipment used to compile that distro on that architecture: there were a few dozen PogoPlugs and similar ziptied to racks with a few "normal" servers providing swap-over-NFS to solve the not-enough-RAM-on-those-bitty-computers problem. Multiply that by the number of distros and number of architectures because I'm sure the others are using similar lashups. Note also that though the Linux distros are coming from x86, nowadays that's getting long in the tooth and the default flavour for many a year now has been AMD64/x86-64. Improved small hardware means things like a Raspberry Pi are more than powerful enough to compile their own code natively, although desktop software is starting to assume 64-bit with huge wodges of memory and becomes problematic on 32-bit even with more RAM than most of us could afford 20 years ago. Meanwhile, the traditional embedded assumption has been that the resources of the target are not sufficient for native compilation, so they go much more for cross-compilers hosted on a reasonably beefy workstation or server. You can even mix-and-match, with an upgraded target device for native compiles but a cross-compiler for developers who need a quick edit-recompile-test loop on one binary, or need to be able to do that on a laptop in the field. Another "gotcha" is that some software wasn't written to cross-compile and has build scripting that _will_ assume the build environment is the target, so if you have any pieces like that then a native compile is the easier route. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Boot problem
Michael Galea via talk wrote: > I am seeing a problem at boot time that has appeared in kernels after > 4.3.0-1-amd64. > > My system will boot, show the available debian kernels, select the > latest and then jump into initramrs. It claims it can not mount dev and > other partitions and, indeed, an ls on the mounted /dev/sda1 shows that > my esata drive has been mounted as root! Debian generates an initramfs at kernel-install time; is it possible that the esata was mounted when you installed that kernel? Maybe run update-initramfs again after booting without the esata connected. Linux can get its own weird ideas about enumeration order of disks, network cards, PCI slots, etc, and that's why we have UUIDs and I thought the Debian initramfs ought to remember the specific UUID of the root device it was generated to use. However, I don't have any Debian-amd64 hardware to check at home here. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Setting up a VM host
William Park via talk wrote: > On Sat, Aug 27, 2016 at 11:53:39AM -0400, Anthony de Boer via talk wrote: > > Also, do please use kernel bridging and not the userspace virtual > > switch. > > Can you elaborate? Is there some parameters at compile time? The qemu manpage where it talks about setting up a TAP interface to talk to a bridge (br0 in the example) should set you on the right path. You'll also want to look at the brctl manpage. Bridging lets the kernel tie together several real and/or virtual interfaces, and in this case can be set up to let your QEMU virtual talk to the LAN. The vde switch it talks about later does not deal well with heavy traffic and will go pear-shaped. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Setting up a VM host
Mike via talk wrote: > I second the vote for qemu-kvm. It seems to be the swiss army knife. The > only thing I've wanted to do with it that I haven't been able to is to boot > 1994 Yggdrasil Linux. The other thing it doesn't do is give you a bunch of virtual machines with collectively more memory than the server has installed. I've had to deal with a box where people had given away 110% of the RAM chips to their various QEMU instances and the server was crawling around on the floor in a very slow and hesitant way. Someone mentioned options: yes, QEMU has a lot of them, and having a script that sets the standard ones and lets you specify just what's different between each one and the next can make starting them a lot easier. QEMU's native commandline can easily start onto a third line on an 80-column screen. Also, do please use kernel bridging and not the userspace virtual switch. If you're running a bunch of heterogenous operating systems, though, QEMU gets you there. I've even seen people use it for Windows. If everything is this-decade Linux then LXC may be an option. It isolates each VM's processes and root filesystem and network interfaces while still sharing memory, CPUs, and (optionally, if VMs are in the same filesystem) disk space. I've run three generations of Debian all under the kernel that came with the latest. If you're also wanting to run eg Fedora then there's a good chance of it just working, or if not you may have to compare kernel configs and build a host kernel that makes everyone happy. LXC lets you run collectively a far bigger party; users have access to all the CPUs and RAM when they have a large compute job, not just the tiny ration the QEMU config sets aside for them. So far I haven't had to configure resource limits on LXC; YMMV. -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Re: [GTALUG] Voting with our Dollars on Computing Future that Respects our Freedom.
Alvin Starr via talk wrote: > The reason for laptop upgrades is often needing more memory or disk > space but by the time you get there 2-3 years down the road the keyboard > has food bits under it and the touch pad is wearing out so getting a new > laptop is the way to go. I had a Thinkpad from around 2000 that lasted more than a decade; it was solid hardware and I didn't abuse it. And ultimately Moore's Law caught up with it, even though I'd maxed out RAM once that got cheap and upgraded the hard drive. I could probably haul it out today and get it booted, but why bother? Lesson from that is buy it to use it not coddle it, and plan to upgrade in not more than five years. Though maybe Moore's Law is levelling out? -- Anthony de Boer --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
