|
So, I'm not totally sure I'm in the right place, but hopefully if I'm not then I can be pointed to the right one. So my workplace has a database that has been running for a long time. So long, in fact, that it was designed to work with a VT100 terminal and nothing else. (There are no plans to replace this system.) We currently use SmarTerm to run an emulated VT100 for whoever needs to work in the database. I don't have control over changing this and neither does our IT team, this was imposed on us by the other division that runs the database. I have nerve issues in my arms and hands. I've been working on paring down as much mouse use as I can, because it aggravates wrist & palm issues for me. I've been almost completely successful... except SmarTerm (and one other in house program that I'm working on getting accessibility methods added to). SmarTerm is so kind as to allow selecting text by mouse, and by mouse only, as the only way to export from this database to plaintext use - nothing confidential, plaintext is fine. SmarTerm... doesn't support a keyboard doing this, at all, because as far as it's concerned I have a VT100's keyboard and that wasn't a thing then. Is there any convenient way I can gently caress around with this to make it work, preferably without external software? I've poked around the configs but I'm working with an emulated terminal older than I am and am pretty out of my depth here.
|
#
?
Feb 16, 2021 22:55
|
|
|
|
| # ? Apr 19, 2024 16:23 |
|
|
Is it safe to assume you need strict VT100 emulation, not "close enough" VT100-ish? Also, how does SmarTerm connect to this database system? Telnet?
|
|
#
?
Feb 16, 2021 23:11
|
|
|
SamDabbers posted:Is it safe to assume you need strict VT100 emulation, not "close enough" VT100-ish? Also, how does SmarTerm connect to this database system? Telnet? I only have user-end access to SmarTerm, so I'm not 100% on the behind-the-scenes aspects here re: the emulation aspect; looks to be using strict emulation currently. Runs over telnet to the datacenter, though, yeah. Set up to only function from specific internal addresses through some VPN scheme (that pulls double duty for fileshare access).
|
|
#
?
Feb 16, 2021 23:20
|
|
|
SecureCRT maybe? Putty supports setting vt100 emulation for Telnet: term=xterm or set term=vt100
|
|
#
?
Feb 17, 2021 00:29
|
|
|
CommieGIR posted:SecureCRT maybe? Putty supports setting vt100 emulation for Telnet: term=xterm or set term=vt100 That just sets what PuTTY reports itself as, but doesn't actually change the way it emulates a terminal. If you need strict VT100 behavior then you need software that advertises that.
|
|
#
?
Feb 17, 2021 00:55
|
|
|
Nitrousoxide posted:Is KVM VMM and Looking Glass the go-to right now for doing pass-through GPU for something like a windows VM in a Linux environment to get (near) bare metal performance? I'm switching over to Linux for my main OS, but there's still a couple of work apps that don't work (well) in Linux and the the windows experience is not super great using its virtual video card. Looking Glass works okay, if you have a second mouse and keyboard. There are some input issues. Remmina (RDP) works pretty well if you don't game.
|
|
#
?
Feb 17, 2021 07:21
|
|
|
CommieGIR posted:SecureCRT maybe? Putty supports setting vt100 emulation for Telnet: term=xterm or set term=vt100 Unfortunately, like I mentioned, not able to make the calls on what software gets used and our IT department's whole flow for the database is built on SmarTerm use. I did reach out before leaving for the day to see if any of the guys who have been around most of that time have answers, at least. 938 pages of documentation on how the system works and it explicitly tells you anyway that all interface controls are in a separate manual.
|
|
#
?
Feb 17, 2021 07:38
|
|
|
It does sound like you would have better chance trying to help your mouse use. Maybe through some of the alternative mouse options, or Windows Ease of Access provides the option to control mouse with keypad, but don't know if that would be precise and convenient enough. Or even eye control.
Saukkis fucked around with this message at 15:26 on Feb 17, 2021 |
|
#
?
Feb 17, 2021 15:24
|
|
|
Does anyone know if Virtualbox has an equivalent to VMware's USB "quirks" setting? I need to be able to set the equivalent of "skip-reset" for a device but there doesn't appear to be a way to do this and their support forums are just awful.
|
|
#
?
Feb 17, 2021 21:49
|
|
|
Bad news: no useful software manuals exist at all. Good news: partially figured it out without the manual. Bad news: the fix without the manual requires writing visual basic that actually compiles and wow is this outside of my skill set.
|
|
#
?
Feb 18, 2021 00:16
|
|
|
I noticed that the USB 3.0 PCI-ex daughterboard I've got plugged into my Windows 10 VM through VMDirectPath I/O wasn't picking up the USB 2.0 device I plugged in, and when I added a USB 2.0 controller through VMDirectPath I/O, something went absolutely apeshit and the audio started stuttering wildly after not playing back for the first minute whenever I'd start something with audio. I'm thinking DPC latency issues caused by lack of MSI-X or something else along those lines, but haven't really got any solution other than using USB 3.0, so my question is: Shouldn't the USB 3.0 controller be capable of picking up USB 2.0 devices, so I don't have to use a separate USB 2.0 controller?
|
|
#
?
Mar 24, 2021 15:39
|
|
|
BlankSystemDaemon posted:I noticed that the USB 3.0 PCI-ex daughterboard I've got plugged into my Windows 10 VM through VMDirectPath I/O wasn't picking up the USB 2.0 device I plugged in, and when I added a USB 2.0 controller through VMDirectPath I/O, something went absolutely apeshit and the audio started stuttering wildly after not playing back for the first minute whenever I'd start something with audio. Yes, USB 3.0 is fully backwards compatible. Sounds like there was an interrupt issue.
|
|
#
?
Mar 24, 2021 15:47
|
|
|
CommieGIR posted:Yes, USB 3.0 is fully backwards compatible. Sounds like there was an interrupt issue. However, I can play X4 perfectly fine (albeit only at 10% better FPS than my former workstation, but that's entirely expected, since I was both CPU and GPU blocked there). Anyway, I'm pretty sure I just need to test a bit more with the HDMI-CEC adapter, as I just had my HOTAS connected to play X4, and that uses USB 2.0 too. Also, from the Linux thread: SamDabbers posted:I look forward to your posts about bhyve It's not using libucl, so it may be refactored again before long, I need to ask jhb@ about it. It'll likely be ready by 13.1, and will probably be in 12.3 as well, given the MFC. Also, even if 13.0-RELEASE isn't out yet (a bug was found, and OpenSSL just announced a high-severity vulnerability has been fixed), the release notes are worth reading through for things like VirtIO V1 (read: Q35 chipset support), 9pfs, snapshots (not live snapshots, yet), as well as a PCI HDAudio device and COM ports 3 and 4. The VNC protocol support has also received a bump, so you can now attach macOS' Screen Sharing feature to it. Oh, and in case you have more memory than should be allowed, you can now use 57-bit virtual addressing and five-layer nested page tables. BlankSystemDaemon fucked around with this message at 02:41 on Mar 25, 2021 |
|
#
?
Mar 25, 2021 02:34
|
|
|
Anyone testing Veeam 11?
|
|
#
?
Mar 26, 2021 01:25
|
|
|
BlankSystemDaemon posted:In most exciting news, bhyve now has proper UCL-like configuration management. This makes it possible to map UCL compatible files onto those OIDs, and it seems to me that it's a pretty excellent GSoC project in case anyone's looking for something to do over the summer. Send me a PM or an email to debdrup@freebsd.org if you're interested.
|
|
#
?
Mar 30, 2021 11:01
|
|
|
 Gaming in Windows on ESXi was a fun adventure, but it doesn't really work out. A combination of a slightly-janky but memory hungry game (X4) and the EFI boot process in ESXi being piss-poor when doing +4GB PCI BARs means that the game seems to freeze when saving. It involved at least two PSODs, and a lot of frustration.
|
|
#
?
Apr 4, 2021 01:42
|
|
|
BlankSystemDaemon posted:
Try KVM with a relatively recent kernel and qemu. I have had good results passing through an Nvidia card and USB3 controller to a Windows VM for this use case under Fedora.
|
|
#
?
Apr 4, 2021 04:06
|
|
|
SamDabbers posted:Try KVM with a relatively recent kernel and qemu. I have had good results passing through an Nvidia card and USB3 controller to a Windows VM for this use case under Fedora. I can pass through the GPU and USB3 daughterboard just fine, that's not the problem. The problem is all the ancillary issues that crop up.
|
|
#
?
Apr 4, 2021 11:13
|
|
|
In what world is systemd worse than anything Windows 
|
|
#
?
Apr 8, 2021 17:08
|
|
|
Mr. Crow posted:In what world is systemd worse than anything Windows This is a rabbithole that will only end in tears and probations  (gently caress systemd, btw)
|
|
#
?
Apr 8, 2021 21:41
|
|
|
Wibla posted:(gently caress systemd, btw) The only position I take on systemd is that I'm glad to have some kind of modern init system as the de facto standard. I was fine with Upstart, and the little I've messed with launchd it seems reasonable as well. You can be anti-systemd all you want, many of the complaints about it are at least based in reality, but anyone who suggests going back to a series of init scripts all executed sequentially and managing their own state however they feel like it needs to be laughed out of the room. wolrah fucked around with this message at 14:46 on Apr 9, 2021 |
|
#
?
Apr 9, 2021 14:44
|
|
|
Systemd is.....meh. I get it, change sucks, but at the same time alot of the change systemd brings is....not really fixing a lot of things. https://ihatesystemd.com/ Biggest thing is changing things that really didn't need to be changed like Networking and other things, and then instead of being consistent, they are changing it AGAIN with the new systemd release. They really are trying to do good things with systemd, but doing so in seemingly the worst and most asinine ways possible CommieGIR fucked around with this message at 16:02 on Apr 9, 2021 |
|
#
?
Apr 9, 2021 16:00
|
|
|
SysV init is not the only way to do things, nor am I especially fond of it, and I'm certainly not recommending anyone go back to it. The suggestion was to not use ESXi and instead use KVM, which means Linux and unless I go out of my way, it also means systemd et al - which is fine except when something inevitably breaks (because it always does, Murphy makes sure of it), I'll want to rootcause it (because that's just the kind of geek I am), and I've been there before, where I end up having to use something other than Linux to do this, which means that little things like log files won't be available to me, because of systemd. Nowhere was there mention of me running Windows as as bare-metal hypervisor, Windows is just the de-facto gaming platform because even if Linux gaming exists, I don't own X4 on Steam (and any other games I play aren't availble on Steam for Linux) and even if I did, I wouldn't know where to start vis-a-vis finding some Linux appliance with Steam that actually works reliably, and probably also involves systemd et al, so we're back to square one. Well, with the exception that at least Windows has dtrace. And speaking of Windows as a bare-metal hypervisor, I wouldn't touch that with a ten-foot pole, because even such a simple thing as IOMMU is an absolute loving pain in the neck to setup and requires messing around in PowerShell. BlankSystemDaemon fucked around with this message at 16:08 on Apr 9, 2021 |
|
#
?
Apr 9, 2021 16:06
|
|
|
wolrah posted:The only position I take on systemd is that I'm glad to have some kind of modern init system as the de facto standard. I was fine with Upstart, and the little I've messed with launchd it seems reasonable as well. I was soured on it by some early implementations that were dogshit, and I am not at all happy with how systemd seems to be spreading like a virus into more aspects of the base OS. Logging is an example that comes to mind (because of corner-cases that lead to weird failures and no logs whatsoever), and networking as has been mentioned. That ihatesystemd.com link that CommieGIR posted mentions some of the core things. Then there's the minor detail that Poettering is an asinine piece of poo poo whose code shouldn't be let near production systems ever, but that's just my personal opinion on a person, so don't take that as gospel  Not that SysV init was perfect, or even good - because it wasn't. But the behaviour was predictable, and it worked well enough.
|
|
#
?
Apr 10, 2021 11:54
|
|
|
The question I want answered is, why are you rebooting your systems often enough that the speed of the reboot matters.
|
|
#
?
Apr 10, 2021 13:17
|
|
|
BlankSystemDaemon posted:The question I want answered is, why are you rebooting your systems often enough that the speed of the reboot matters.
|
|
#
?
Apr 10, 2021 18:43
|
|
|
That ihatesystemd website is so barebones that, like, as someone without strong feelings in any particular direction it feels more like an angry outcry than anything substantial. Anyone could write a similar length tangent about the good/bad/ugly of just about any OS or application. Christ, I could write a more robust webpage on the inanities of SCCM, and I'm not even an SCCM admin, just a guy who has to deal with it sometimes. Like: quote:The Active: inactive (dead) line does not mean that it is active. It is dead, and has been for 2 minutes and 14 seconds. If it was active, it would say Active: active. Obviously. Yeah, okay, it should read "Activity: inactive (dead)", sure, we get it. Yes, actually, it is obvious to anyone who is literate. Yes, it is phrased poorly, sure, fine, but I don't know about writing a goddamn blog about it.
|
|
#
?
Apr 10, 2021 20:35
|
|
|
I only manage my own home server and a few low-importance systems used inside test environments at work so I'll freely admit I'm not an expert, but systemd seems pretty functional to me and I've never been motivated to try to replace it. I looked at the ihatesystemd stuff and there's some "I don't think like the developers and don't like how they handled this edge case", some "this very complicated software undergoing continual development occasionally has BUGS!", and some "this very complicated software sometimes forces you to do things in complicated ways!" As someone who has tested closed-source enterprise software for several years, none of this seems notable let alone crippling. If systemd is so bad, why is it incredibly popular - just inertia and network effect? Seems like you would at the very least have popular forks out there, if not ground-up replacements. Eletriarnation fucked around with this message at 21:05 on Apr 10, 2021 |
|
#
?
Apr 10, 2021 21:03
|
|
|
Well, systemd is popular for a few reasons. Partially it's because RedHat are well-positioned to affect a lot of other distributions, since a lot of distributions take cues from how RedHat does things, if they don't directly consume most of what's being offered and just alter a few bits and bobs. Secondly, because a lot of the non-RedHat-affected distributions adopted systemd early on, pretty much through unilateral decisions by a few people (Debian was one of the few places where there was any substantive debate, and even then it was still decided to adopt it - and even more things are based on Debian than are based on RedHat stuff). There's also a very substantial userbase of Linux users who's happily act like Windows users and just reboot when they encounter problems, instead of roocausing them, so when they do encounter problems, they won't know what's the cause (although this doesn't mean systemd is always at fault, naturally). This, ironically, is probably also the userbase that's most convinced by the "it boots faster" argument, although that one has arguably been shown to be largely untrue for newer versions, if it ever was faster. Someone more clever than me can probably also comment on how something doesn't have to be good to be popular. I think a lot of it comes down to the fact that it's a compound thing for the people who don't like systemd; ie. it's not just systemd itself, it's also Lennart Poettering, RedHat, and a bunch of other factors. To add to the other link, there's also an (archived) list of articles critical of systemd as well as some (archived) arguments against systemd. EDIT: For reference, I'm not saying that none of the things systemd does is good - however everything good that it does has been done better and before it by launchd (introduced in Mac OS X, still in macOS, and is an on-demand unit-structured startup handler that replaced BSD init - it only starts up things when there's an actual demand for them by using sockets not unlike how inetd launches daemons on demand, and it also handles units in a way that'd be familiar to a systemd user) and SMF (Solaris Management Facility, one of the only startup processes that've managed to produce a graph that can't get you into a failed state). Had I the money for it, I wouldn't mind paying someone to make something for FreeBSD out of BSD init, rc, devd, daemon, and all the utilities that're already in base and could be used to achieve all of this, without making a monolithic beast that's consuming seemingly all of the Linux userland. BlankSystemDaemon fucked around with this message at 23:02 on Apr 10, 2021 |
|
#
?
Apr 10, 2021 22:47
|
|
|
Conversely a lot of people dislike it for completely arbitrary and personal reasons and refuse to use it despite it being objectively better than anything that came before. Just your typical Linux user wars, is you like it keep using it
|
|
#
?
Apr 10, 2021 23:03
|
|
|
If it's objectively better, how can it get into a state when the system is unbootable without the configuration being touched by the user? Let me guess, "it works for me" - which is the exact response a lot of people get when they report real bugs and Lennart doesn't wanna bother with something.
|
|
#
?
Apr 10, 2021 23:25
|
|
|
BlankSystemDaemon posted:If it's objectively better, how can it get into a state when the system is unbootable without the configuration being touched by the user? Elaborate
|
|
#
?
Apr 10, 2021 23:26
|
|
|
jaegerx posted:Elaborate As a personal anecdote, the last time I was running a Linux distribution on my entire network, it managed to stop booting properly, and when I checked things with zfs-diff(8); no changes related to systemd or its configuration - nor had anything else had changed, only a couple of files of userdata. That was pretty much the last straw, for me. BlankSystemDaemon fucked around with this message at 23:34 on Apr 10, 2021 |
|
#
?
Apr 10, 2021 23:28
|
|
|
BlankSystemDaemon posted:Well, systemd is popular for a few reasons. I appreciate the insight here. I guess some of it just opens up more questions though - Red Hat, being responsible for countless actual paid-support production systems, surely had good reasons for choosing systemd over... whatever they were using before, right? If launchd and SMF are better and older, why did systemd choose a different path for what it's doing and why did everyone (in Linux-land, at least) go along with that? I don't expect you to educate me on the history of all this, but it feels like there's more going on here than the Linux userbase not knowing a good init system from a bad one. BlankSystemDaemon posted:As a personal anecdote, the last time I was running a Linux distribution on my entire network, it managed to stop booting properly, and when I checked things with zfs-diff(8); no changes related to systemd or its configuration - nor had anything else had changed, only a couple of files of userdata. If nothing changed related to systemd, what made you think that the problem was caused by it? Eletriarnation fucked around with this message at 00:06 on Apr 11, 2021 |
|
#
?
Apr 10, 2021 23:59
|
|
|
BlankSystemDaemon posted:If it's objectively better, how can it get into a state when the system is unbootable without the configuration being touched by the user? I've also been bitten by that poo poo in the early days, went back to Debian (that hadn't implemented systemd as a default yet)... BlankSystemDaemon posted:There's a lot of bugs that're closed on the official bug tracker (and even more bugs that were never filed as such, but have just been blogged about, because the people who blog about them know Lennarts attitude) without any resolution given, despite plenty of rootcausing having been done by the bug reporter. Bolded bits very relevant. Eletriarnation posted:I appreciate the insight here. I guess some of it just opens up more questions though - Red Hat, being responsible for countless actual paid-support production systems, surely had good reasons for choosing systemd over... whatever they were using before, right? If launchd and SMF are better and older, why did systemd choose a different path for what it's doing and why did everyone (in Linux-land, at least) go along with that? I don't expect you to educate me on the history of all this, but it feels like there's more going on here than the Linux userbase not knowing a good init system from a bad one. Lennart Poettering has been employed by Red Hat since 2008. You do the math.
|
|
#
?
Apr 11, 2021 00:17
|
|
|
BlankSystemDaemon posted:The question I want answered is, why are you rebooting your systems often enough that the speed of the reboot matters. the free proxmox repository updates the damned kernel quite a lot
|
|
#
?
Apr 11, 2021 00:41
|
|
|
Anyone try out TrueNAS Scale yet? What are your thoughts? I started with FreeNAS passthru'ed on ESXI, then went to Proxmox with the same ZFS pool. But I could see TrueNAS Scale instead for the way that it's embracing k8s and docker vs Proxmox position of "LXC For everything"
|
|
#
?
Apr 11, 2021 01:31
|
|
|
BlankSystemDaemon posted:As a personal anecdote, the last time I was running a Linux distribution on my entire network, it managed to stop booting properly, and when I checked things with zfs-diff(8); no changes related to systemd or its configuration - nor had anything else had changed, only a couple of files of userdata. So systemd was the cause of this how? Or did you just assume it was at fault?
|
|
#
?
Apr 11, 2021 05:17
|
|
|
Eletriarnation posted:I appreciate the insight here. I guess some of it just opens up more questions though - Red Hat, being responsible for countless actual paid-support production systems, surely had good reasons for choosing systemd over... whatever they were using before, right? If launchd and SMF are better and older, why did systemd choose a different path for what it's doing and why did everyone (in Linux-land, at least) go along with that? I don't expect you to educate me on the history of all this, but it feels like there's more going on here than the Linux userbase not knowing a good init system from a bad one. RedHat was looking to replace SysV init, because it needed replacing, and Lennart Poettering was in the right place at the right time. It also doesn't hurt that RedHat makes money on selling support contracts, and that a non-zero amount of companies moved to paid support, because of systemd. Eletriarnation posted:If nothing changed related to systemd, what made you think that the problem was caused by it? Mr. Crow posted:So systemd was the cause of this how? Or did you just assume it was at fault? If it'd been FreeBSD, I'd have run rcorder /etc/rc.d /usr/local/etc/rc.d a whole bunch of times and looked for differences, but systemd-analyze only prints the last successful boot, it doesn't simulate a new one. The system in question had ECC memory which I checked by using a known-bad DIMM. I replaced the PSU, and did a bunch of other testing including moving it to a completely different system (virtualized on known-good hardware), none of which isolated the problem. BlankSystemDaemon fucked around with this message at 10:02 on Apr 11, 2021 |
|
#
?
Apr 11, 2021 09:57
|
|
|
|
| # ? Apr 19, 2024 16:23 |
|
|
Sure, I know that they couldn't just wholesale lift closed source software - what I'm saying is that if Poettering set out to emulate those examples knowing how they work, it doesn't really make sense that what he developed would just be worse for no reason instead of working in the same way as the examples. At the very least, we have to claim that he didn't know what he was doing or that he made bad decisions on how to make necessary-for-Linux changes instead of just replicating what was in front of him. I don't even know the specifics of how they are different because I've never gone into the weeds that far on OSX or used BSD at all, so I'm not going to speculate on why those decisions were made - if you want to say that he made a mistake because he has bad opinions on how things should work, OK. But... like you say, he was in the right place at the right time to solve a problem that needed solving. Not only was his employer who paid for the solution happy to use it, but most of the rest of the Linux world was too. Even if I believe that Red Hat created a deliberately flawed solution to sell more support contracts (or for the less conspiracy minded, spent a while developing something lovely and fell victim to sunk cost fallacy), for me it doesn't really pass the laugh test that the rest of the open source world would say "well, ok" and get in line and stay there for ten years instead of forking or starting over from scratch. Eletriarnation fucked around with this message at 14:58 on Apr 11, 2021 |
|
#
?
Apr 11, 2021 14:53
|
|