|
tonberrytoby posted:I can't find the reports now either. I think they were already hard to find back then even with the exact log. Don't take this the wrong way, but this entire thing is a non-argument. There's no technical basis for this and no way to refute your feelings. But: "systemd has less advantages than PA" -> maybe if you have no idea what systemd does or what its alternatives do/don't do. conflating pulseaudio and the kernel again. But Pulse really, really doesn't directly interface with the kernel. Anywhere. At all. It uses ALSA directly, and presents a sink to other ALSA applications so it can mix them. A trivial review of the source would show you this. Can't find the bugs. Welp, can't comment on that either way. Don't install systemd if you don't want to. Or anything else. But please stop making wishy-washy appeals to emotion.
|
#
?
Mar 30, 2015 19:24
|
|
|
|
| # ? Jun 4, 2024 11:22 |
|
|
I generally just read any posts regarding systemd, as I don't feel educated enough to contribute, but just felt like mentioning that as a long-time Linux user I was aware of the furor regarding it, and was mildly leery when I upgraded from OpenSUSE 12.2 to 12.3, as it was the point where they adopted it. It has been a complete non-issue for me. In the same vein I avoided GRUB 2 for a period of time, but had zero issues after it became the default. I've been running Linux as a desktop OS since at least 2003, and it sometimes seems to me that one of the greatest sources of FUD about Linux has come from inside the community itself.
|
|
#
?
Mar 31, 2015 04:23
|
|
|
evol262 posted:While "works for me" is a bad way to resolve it, the PA guys (and Lennart in particular) are not responsible for implementation details on other distros, and saying "that's a kernel bug which we don't have in Fedora, so it's your broken poo poo" is also a valid reponse. To a casual (non-enterprise) user, are there advantages to using Fedora because it's the environment closest to what key developers use?
|
|
#
?
Mar 31, 2015 15:54
|
|
|
i switched from using debian/mint/ubuntu to fedora and it is amazing how everything just works, whereabouts in those other 3 there would be hours of changing things
|
|
#
?
Mar 31, 2015 16:00
|
|
|
Celexi posted:i switched from using debian/mint/ubuntu to fedora and it is amazing how everything just works, whereabouts in those other 3 there would be hours of changing things
|
|
#
?
Mar 31, 2015 16:15
|
|
|
Prince John posted:To a casual (non-enterprise) user, are there advantages to using Fedora because it's the environment closest to what key developers use?
|
|
#
?
Mar 31, 2015 17:40
|
|
|
Having issues with a pptp connection dropping all the time. Symptoms are connection hangs with no response from remote, but pptp process is still running. Client is centos 6 pptp client, remote is windows 2008 RRAS as far as I know, Mar 31 18:36:41 SERVERNAMEHERE pppd[9477]: pppd 2.4.5 started by root, uid 0 Mar 31 18:36:41 SERVERNAMEHERE pppd[9477]: Using interface ppp0 Mar 31 18:36:41 SERVERNAMEHERE pppd[9477]: Connect: ppp0 <--> /dev/pts/1 Mar 31 18:36:41 SERVERNAMEHERE pptp[9478]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated Mar 31 18:36:41 SERVERNAMEHERE pptp[9489]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Mar 31 18:36:41 SERVERNAMEHERE pptp[9489]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply Mar 31 18:36:41 SERVERNAMEHERE pptp[9489]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established. Mar 31 18:36:42 SERVERNAMEHERE pptp[9489]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Mar 31 18:36:42 SERVERNAMEHERE pptp[9489]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply. Mar 31 18:36:42 SERVERNAMEHERE pptp[9489]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 46165). Mar 31 18:36:43 SERVERNAMEHERE pptp[9489]: anon log[ctrlp_disp:pptp_ctrl.c:950]: PPTP_SET_LINK_INFO received from peer_callid 0 Mar 31 18:36:43 SERVERNAMEHERE pptp[9489]: anon log[ctrlp_disp:pptp_ctrl.c:953]: send_accm is 00000000, recv_accm is FFFFFFFF Mar 31 18:36:43 SERVERNAMEHERE pptp[9489]: anon warn[ctrlp_disp:pptp_ctrl.c:956]: Non-zero Async Control Character Maps are not supported! Mar 31 18:36:43 SERVERNAMEHERE pppd[9477]: CHAP authentication succeeded Mar 31 18:36:43 SERVERNAMEHERE pppd[9477]: MPPE 128-bit stateless compression enabled Mar 31 18:36:44 SERVERNAMEHERE pppd[9477]: local IP address 192.168.5.197 Mar 31 18:36:44 SERVERNAMEHERE pppd[9477]: remote IP address 192.168.5.192 then lots of Mar 31 18:36:52 SERVERNAMEHERE pptp[9478]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 52 (expecting 51, lost or reordered) Mar 31 18:36:52 SERVERNAMEHERE pptp[9478]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 82 (expecting 81, lost or reordered) Mar 31 18:36:52 SERVERNAMEHERE pptp[9478]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 98 (expecting 97, lost or reordered) From googling there is some suggestions of mtu problems being the root cause but it will log those errors even with only pings are being sent across the vpn Any help debugging this appreciated
|
|
#
?
Mar 31, 2015 19:02
|
|
|
ExcessBLarg! posted:If you want to run a vanilla GNOME desktop on standard PC hardware, yes. ARM is also a first-class architecture, and POWER7/8 support is very good
|
|
#
?
Mar 31, 2015 23:40
|
|
|
evol262 posted:ARM is also a first-class architecture, and POWER7/8 support is very good Don't forget Apple hardware, if that still works well. Most people don't connect that to 'standard PC'. I prefer Fedora over other distros since my work is largely on CentOS/RHEL.
|
|
#
?
Apr 1, 2015 03:12
|
|
|
Celexi posted:i switched from using debian/mint/ubuntu to fedora and it is amazing how everything just works, whereabouts in those other 3 there would be hours of changing things Yeah I've really been impressed with fedora 21. It's certainly been the smoothest setup I've had for a long time.
|
|
#
?
Apr 1, 2015 10:36
|
|
|
Does anyone know of a "commercial" backup solution that can have backup agents on multiple machines pushing backups to a central location before going offsite? I've been using Crashplan at home for a couple years and while it works well, it only pushes the local backups on my media server to S3 while storing backups from other machines locally. I've looked around a little and there aren't many that support that multi-agent architecture I've been using.
|
|
#
?
Apr 1, 2015 11:34
|
|
|
evol262 posted:ARM is also a first-class architecture, That's not really a Fedora problem though, that's an ARM Linux problem.
|
|
#
?
Apr 1, 2015 14:30
|
|
|
arm is bad
|
|
#
?
Apr 1, 2015 14:43
|
|
|
ExcessBLarg! posted:Which boards are supported though? ARM isn't a standardized platform like PCs are. Boards most often require a custom kernel binary, if not custom kernel sources. Device Trees are supposed to help this, and maybe the situation has gotten a little better, but two years ago it was an absolute mess. So in practice, non-hardware-specific distributions support a few boards maybe OK. Basically any armv7+ board you're likely to encounter, and aarch64 support is happening. This is because u-boot is relatively standard, and a relatively generic kernel can be used. If you've got some exynos thing that needs an awful out-of-tree kernel like the odroid, though... I recommend cubietrucks to everyone interested in arm, basically
|
|
#
?
Apr 1, 2015 14:58
|
|
|
Sitting next to me I have an Exynos laptop (Samsung Chromebook 2), and three Qualcomm Snapdragon devices (Samsung Galaxy S3, S4, and a Nexus 7). All of those ship with a Linux-based kernel, and they're all capable of running unsigned (or consistently-signed) kernels. They're also particularly compelling devices to run a Linux GUI on as they have lovely screens and such. Does Fedora run on any of them?
|
|
#
?
Apr 1, 2015 15:34
|
|
|
A simple yum update on a customer's CentOS 7 box has rendered it unbootable on our platform (Xen + PyGrub). I just tested this with a freshly installed CentOS 7 box on a different dom0 and had the same result. Editing grub.conf to restore the old kernel causes it to boot right back up. It appears that the RPM install for the new kernel isn't installing an initrd in /boot/grub/grub.conf for some reason.pre:[2023342.811485] List of all partitions: [2023342.811488] No filesystem could mount root, tried: [2023342.811492] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [2023342.811497] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.10.0-229.1.2.el7.x86_64 #1 [2023342.811501] ffffffff818141a8 00000000c305ff94 ffff8800f8b87d60 ffffffff81604afa [2023342.811506] ffff8800f8b87de0 ffffffff815fe36e ffffffff00000010 ffff8800f8b87df0 [2023342.811511] ffff8800f8b87d90 00000000c305ff94 00000000c305ff94 ffff8800f8b87e00 [2023342.811516] Call Trace: [2023342.811524] [<ffffffff81604afa>] dump_stack+0x19/0x1b [2023342.811528] [<ffffffff815fe36e>] panic+0xd8/0x1e7 [2023342.811533] [<ffffffff81a4560d>] mount_block_root+0x2a1/0x2b0 [2023342.811537] [<ffffffff81a4566f>] mount_root+0x53/0x56 [2023342.811540] [<ffffffff81a457ae>] prepare_namespace+0x13c/0x174 [2023342.811544] [<ffffffff81a4527b>] kernel_init_freeable+0x203/0x22a [2023342.811548] [<ffffffff81a449db>] ? initcall_blacklist+0xb0/0xb0 [2023342.811552] [<ffffffff815f2fb0>] ? rest_init+0x80/0x80 [2023342.811556] [<ffffffff815f2fbe>] kernel_init+0xe/0x180 [2023342.811559] [<ffffffff8161497c>] ret_from_fork+0x7c/0xb0 [2023342.811563] [<ffffffff815f2fb0>] ? rest_init+0x80/0x80 pre:title CentOS Linux (3.10.0-229.1.2.el7.x86_64) 7 (Core) root (hd0,0) kernel /boot/vmlinuz-3.10.0-229.1.2.el7.x86_64 console=hvc0 xencons=tty0 root=/dev/xvda1 ro LANG=en_US.UTF-8 title CentOS Linux (3.10.0-123.20.1.el7.x86_64) 7 (Core) root (hd0,0) kernel /boot/vmlinuz-3.10.0-123.20.1.el7.x86_64 console=hvc0 xencons=tty0 root=/dev/xvda1 ro initrd /boot/initramfs-3.10.0-123.20.1.el7.x86_64.img title vmlinuz-3.10.0-123.4.4.el7.x86_64 root (hd0,0) kernel /boot/vmlinuz-3.10.0-123.4.4.el7.x86_64 console=hvc0 xencons=tty0 root=/dev/xvda1 ro initrd /boot/initramfs-3.10.0-123.4.4.el7.x86_64.img pre:System.map-3.10.0-123.20.1.el7.x86_64 System.map-3.10.0-123.4.4.el7.x86_64 System.map-3.10.0-229.1.2.el7.x86_64 config-3.10.0-123.20.1.el7.x86_64 config-3.10.0-123.4.4.el7.x86_64 config-3.10.0-229.1.2.el7.x86_64 grub grub2 initramfs-3.10.0-123.20.1.el7.x86_64.img initramfs-3.10.0-123.4.4.el7.x86_64.img initramfs-3.10.0-229.1.2.el7.x86_64.img symvers-3.10.0-123.20.1.el7.x86_64.gz symvers-3.10.0-123.4.4.el7.x86_64.gz symvers-3.10.0-229.1.2.el7.x86_64.gz vmlinuz-3.10.0-123.20.1.el7.x86_64 vmlinuz-3.10.0-123.4.4.el7.x86_64 vmlinuz-3.10.0-229.1.2.el7.x86_64 Upon further review, I'm even more confused. I did a straight yum update kernel on a fresh install and it installed the kernel properly, with the initrd referenced. However, when I do a full yum update it gives me a broken grub.conf. Anyone have any ideas why this might be, or is this weird enough that I should take it to the CentOS mailing list? Update: Adding grubby and grub2* to excludes in yum.conf seems to do the trick. Looks like an update to one of those packages broke this - likely grubby. Thalagyrt fucked around with this message at 17:41 on Apr 1, 2015 |
|
#
?
Apr 1, 2015 15:37
|
|
|
Chiming in to report that it was, in fact, my CentOS 7 box that I just updated last night. A bug report on the subject at RHEL Bugzilla would seem to indicate that this is a regression in grubby, affected by a change in the kernel update process that was introduced when yum updated my machine from CentOS 7 to 7.1. Specifically, 7.1 introduces the use of the grubby parameter --title, which sets the title of the boot option to be added. Apparently, it also prevents grubby from adding the newly generated initrd to the boot entry as well. The problem does not occur in CentOS 7.0, which does not pass the --title parameter. It may also be a newly introduced regression in grubby. One of my friends swears by RedHat. And here we have a dist upgrade that breaks booting, straight from RedHat. Thalagyry tells me he's never seen Debian kernel updates that break the system. Who knows, that may actually have happened at some point in the past. He also chewed me out for not filing the ticket as Critical. I filed it as Normal instead, even though technically, my server hosts my web site, which also hosts my Cog audio player fork, as well as updates for the update checker. For all five of the people who use it, I guess. Then again, I also gave the abdominal pain I was experiencing in the hospital while waiting for my appendectomy surgery as a 4.5 out of 10, while the guy next to me who dropped something on his foot rated that as a 9.
|
|
#
?
Apr 2, 2015 04:43
|
|
|
kode54 posted:Chiming in to report that it was, in fact, my CentOS 7 box that I just updated last night. Debian has, in fact, repeatedly broken upgrades. Nobody's really immune from this, including Microsoft, Apple, Debian, and Google. Red Hat's release engineering is arguably better than most (especially most Linux distros), but not perfect. That bug looks very muddled. And recycled (same bug ID re-used, which means a lot of the comments aren't meaningful). Are you upgrading from 7.0 to 7.1, or 6.something to 7.1?
|
|
#
?
Apr 2, 2015 14:31
|
|
|
Ubuntu has been really bad lately with having to pull lovely updates
|
|
#
?
Apr 2, 2015 14:36
|
|
|
kode54 posted:Chiming in to report that it was, in fact, my CentOS 7 box that I just updated last night. Reread this. A couple things: We don't care what priority you set it to. We care what priority pm sets it to and whether it's a blocker (a flag you can't set). Debian's dist-upgrade has a meaning that doesn't matter in the context of yum. But major distribution upgrades were not supported before rhel7, and the tool is brand new. Explicitly because of stuff like this. The RHEL branching timeline is unlike anything Debian does. I've mentioned it before, but I pretty much built my career on developing custom upgrade paths in place between major RHEL versions (I guess the last bit I did for 5->6 could theoretically convert rhel5 to anything, and I actually used it to go from rhel5 to Gentoo in a few cases where we didn't have ipmi access). The companies I was doing it for needed to get Red Hat out to certify it. Because it's really hard and there are a lot of moving pieces. Between rhel6 and 7, the boot loader changed, the init system changed, /[s]bin moved into /usr, and kernel 3 happened, and those are just fundamental platform things. Also, I don't know if preupgrade installs grub2 or stays with regular grub, which introduces another variable. Are you still on grub-legacy, or grub2?
|
|
#
?
Apr 2, 2015 14:49
|
|
|
evol262 posted:Reread this. A couple things: He was talking about the ticket with us. He set it to normal and I gave him a hard time for not setting it to critical to get my attention at 4AM because his stuff was hard down. Normal tickets wait 18 hours before escalating to phone calls while critical tickets don't wait at all and start calling our team immediately, which gets quick attention at 4AM when he opened the ticket and we were all asleep. I have no doubts that some Debian kernel updates have broken things, however the last time I've seen a Debian kernel update render a system non-bootable was in the Debian 4 days. I've never seen a kernel update in Ubuntu 10+ and Debian 5+ render the system unbootable, and I deal with these Debian and Ubuntu systems day in and day out and have for quite a while. To be fair, this is the first time I've seen a screwup in RHEL/derivatives in a long time too, so you guys are doing a stellar job. It was just a bit shocking because I'm so used to yum update just working. Kode's upgrade was from 7.0 to 7.1, and his box uses a legacy grub config file because it's booting via PyGrub on Xen. Somewhere along the line this release of Grubby got screwy and is leaving systems that depend on it to update /boot/grub/grub.conf unbootable due to this regression. Working around it was pretty easy as I just added grubby to excludes in our images going forward, but I really shouldn't have to do that. Thalagyrt fucked around with this message at 17:23 on Apr 2, 2015 |
|
#
?
Apr 2, 2015 17:18
|
|
|
Thalagyrt posted:He was talking about the ticket with us. He set it to normal and I gave him a hard time for not setting it to critical to get my attention at 4AM because his stuff was hard down. Normal tickets wait 18 hours before escalating to phone calls while critical tickets don't wait at all and start calling our team immediately, which gets quick attention at 4AM when he opened the ticket and we were all asleep.
|
|
#
?
Apr 2, 2015 19:02
|
|
|
Thalagyrt posted:He was talking about the ticket with us. He set it to normal and I gave him a hard time for not setting it to critical to get my attention at 4AM because his stuff was hard down. Normal tickets wait 18 hours before escalating to phone calls while critical tickets don't wait at all and start calling our team immediately, which gets quick attention at 4AM when he opened the ticket and we were all asleep. This sounds like a QE failure. I don't know if there's a test case for this or not, but that bug is absolutely not the correct one to be looking at. It got pushed because preupgrade apparently has a workaround for this, and the assignee asked for new bugs to be opened. A quick look at Bugzilla didn't show me anything, so you should open a new bug. I very much doubt if anybody is aware that there's a broken case. File a new bug.
code:
|
|
#
?
Apr 2, 2015 19:19
|
|
|
evol262 posted:This sounds like a QE failure. I don't know if there's a test case for this or not, but that bug is absolutely not the correct one to be looking at. It got pushed because preupgrade apparently has a workaround for this, and the assignee asked for new bugs to be opened. Bug's submitted. Hopefully I didn't miss anything important! https://bugzilla.redhat.com/show_bug.cgi?id=1208653
|
|
#
?
Apr 2, 2015 20:15
|
|
|
Sorry if I thought that bug report was relevant. It was vaguely related, and the comment I directly linked, #26, did mention that this issue was appearing again in 7.1, but it did deserve a new bug report.
|
|
#
?
Apr 3, 2015 01:58
|
|
|
kode54 posted:Sorry if I thought that bug report was relevant. It was vaguely related, and the comment I directly linked, #26, did mention that this issue was appearing again in 7.1, but it did deserve a new bug report. It's hard to tell sometimes as an end user, because you read it and say 'hey, that looks like my problem!' But the devil is the details. Most of our bugs are filed internally by QE or engineering against other products ("I'm using foo to do bar and it's not working as expected, here's how to get it to"), and sometimes from support. But everyone internally kinda knows what a good bug has because we've seen a million of them. It was about 7.1, and it may be the same root cause. But it may not be (probably is). And the fact that pygrub isn't indicated anywhere in the bug or PV guests leads me to believe that nobody knows it's happening there. The developer looked at it from a preupgrade perspective, and they said "we have this fixed from our end", so he's not prioritizing a fix right now. Filing a new bug which explicitly mentions those things is good for a few reasons, even if it gets closed as a duplicate of the one you linked (and judging from the last comment, it won't):
Finding (and reading) bugs is hard.
|
|
#
?
Apr 3, 2015 02:19
|
|
|
evol262 posted:Finding (and reading) bugs is hard. Truth. When I was in college I did volunteer QA work for Mozilla in the Firefox 1.0ish timeframe. A LOT of what we did was simply triage incoming bug reports and mark them as duplicates of existing issues in Bugzilla. That's no slight on the users reporting the bugs; the bug tracker for any moderately large project is going to be pretty inscrutable to most users, even someone technical. Finding the exact right issue (unless it's super high profile) often takes a lot of domain / jargon knowledge. And as evol mentioned, it was still helpful information. Seeing a bug with 50 dupes is the same as seeing one with 50 "me too!" comments in terms of judging the scope of the problem. If anyone reading this wants to dip their toes into open source contribution, think about helping out with bug triage on a large project. There's never enough people doing it so it will be massively appreciated right away by the project developers and leadership. And while it can be kind of boring, it's directly usable on-the-job experience. To this day I have coworkers asking "how the HELL did you find that on Google/our wiki/source control/whatever" and I attribute that to the practice I got trolling through Bugzilla all day 
|
|
#
?
Apr 3, 2015 04:01
|
|
|
(Talking about how to keep my larger monitor as the primary and not the smaller monitor, so that Steam games will start in the big one and not the little one)reading posted:This did it! I deleted the /etc/X11/xorg.conf and used the nvidia command panel to write a new one. Thanks! Now I'm having the issue that every time I restart, the smaller monitor gets placed back as the primary. How can I make this thing stop doing that, and keep my xorg.conf permanently?
|
|
#
?
Apr 3, 2015 04:05
|
|
|
reading posted:(Talking about how to keep my larger monitor as the primary and not the smaller monitor, so that Steam games will start in the big one and not the little one) Ghetto way? Chattr.
|
|
#
?
Apr 3, 2015 05:55
|
|
|
reading posted:(Talking about how to keep my larger monitor as the primary and not the smaller monitor, so that Steam games will start in the big one and not the little one) use something other than xfce, xfce is bad with games, and linux mint desktop manager is not great either
|
|
#
?
Apr 3, 2015 06:16
|
|
|
evol262 posted:Basically any armv7+ board you're likely to encounter, and aarch64 support is happening. I'm running the odroid-c1 and I'm pretty sure I'm going to go with something that can use generic kernels when I upgrade in a couple years. I can always pull their kernel source and compile my own to run another distro but when they stop updating it when they launch their next board (I hope not but they've done it in the past) I'll be boned either way. E: Actually I think they're just not doing updates for the odroid board that was the same formfactor as the Pi B+. As of now the XU series boards still get regular updates at least.
|
|
#
?
Apr 3, 2015 19:47
|
|
|
This might be hopelessly remedial, but I thought I would mention that there was a Windows update released last week that will fail if you run a dual-boot configuration or use a bootloader other than the Windows one. It's got a pretty easy workaround, just requiring a manual selection of the Windows drive from the one-time boot menu and thus using the Windows bootloader, but it failed on me several times before I bothered looking up the error and figured I might be able to save someone else the frustration.
|
|
#
?
Apr 3, 2015 22:17
|
|
|
CaptainSarcastic posted:This might be hopelessly remedial, but I thought I would mention that there was a Windows update released last week that will fail if you run a dual-boot configuration or use a bootloader other than the Windows one. As in, windows will boot fine if you boot straight into the windows VBR, but not if you load grub or syslinux and then chainload the windows VBR from there? How do they even gently caress it up that badly?
|
|
#
?
Apr 4, 2015 03:41
|
|
|
ToxicFrog posted:As in, windows will boot fine if you boot straight into the windows VBR, but not if you load grub or syslinux and then chainload the windows VBR from there? Yep. Since my system starts off with GRUB2 the update just failed (after several minutes of thinking, and then several more of undoing itself), and generated an error that I found surprising enough to take a picture of:  I spent a lot of time doing Windows installs and reinstalls over the years, and don't remember anything quite like this popping up when Windows Update went sideways. After the second failure I finally looked it up and found it was a known issue with this update. Nice of them to have a warning about it or give any indication beforehand that it would crap out on anything other than a vanilla Windows install.
|
|
#
?
Apr 4, 2015 03:59
|
|
|
Without looking explicitly, I would guess that this is a secureboot issue. Are you running with secureboot off?
|
|
#
?
Apr 4, 2015 05:50
|
|
|
This mobo is just old enough to not have secureboot - it's a socket AM3 board with fairly old-school BIOS. The update in question is the one this knowledge base article is on: http://support.microsoft.com/en-us/kb/3033929
|
|
#
?
Apr 4, 2015 07:40
|
|
|
Can somebody tell me if there's a simple way to rig this up with command line utilities, or a tool that provides this functionality? I have an idea for an implementation, but I want to see if it exists already. If we have a daemon that continuously reads from standard input and writes to standard output, I want to run a group of those daemons, and have every line of input from every process be sent to every process in the group (including itself). I think that if it were sufficiently abstracted there could be plugins to run the processes over a network, or use decentralized messaging algorithms. In more detail, we could say two Ruby scripts watch /var/worker and /var/application respectively, accepting requests and commands. Both of them write output to /var/sink. This hypothetical program monitors /var/sink and manages reading, buffering and writing to /var/worker and /var/application. Basically, a message broker that works on standard IO. All of those things are either UNIX sockets or FIFO pipes or something like that. (I would make a separate program to manage clustering. For example, P2P discovery through gossip, and dynamically updating the sockets that /var/sink will direct to.) xtal fucked around with this message at 23:01 on Apr 4, 2015 |
|
#
?
Apr 4, 2015 22:57
|
|
|
Are you talking about worker queues like beanstalkd?
|
|
#
?
Apr 4, 2015 23:07
|
|
|
waffle iron posted:Are you talking about worker queues like beanstalkd? That's the same concept but I don't want this to use a client library, just standard I/O, and maybe signals if we wanted to get really crazy. The idea is abstracting out the message queue into three interoperable components: one that finds other nodes and opens a bunch of UNIX sockets, one that multiplexes all of those into a single socket, and one that wraps a program's standard I/O to use those interfaces. That way I can start with simple clusters (a bunch of Rake tasks for example) but also replace different components to do more advanced things (run the tasks on EC2, find other nodes with a gossip protocol).
|
|
#
?
Apr 4, 2015 23:24
|
|
|
|
| # ? Jun 4, 2024 11:22 |
|
|
xtal posted:That's the same concept but I don't want this to use a client library, just standard I/O, and maybe signals if we wanted to get really crazy. The idea is abstracting out the message queue into three interoperable components: one that finds other nodes and opens a bunch of UNIX sockets, one that multiplexes all of those into a single socket, and one that wraps a program's standard I/O to use those interfaces. That way I can start with simple clusters (a bunch of Rake tasks for example) but also replace different components to do more advanced things (run the tasks on EC2, find other nodes with a gossip protocol). These kinds of things invariably talk over a message queue, which is also what you wanna use. Even redis or etcd would be ok, but pub/sub message queues.
|
|
#
?
Apr 5, 2015 01:54
|
|