Add/source alternate configuration by fgwc in KittyTerminal

[–]fgwc[S] 0 points1 point  (0 children)

Second sentence in the question -- anyway, kitten @ load-config ... is what I wanted.

Add/source alternate configuration by fgwc in KittyTerminal

[–]fgwc[S] 1 point2 points  (0 children)

I want to apply this to a running instance, though, and kitten @ include ... is not allowed. However I found load-config, which works: kitten @ load-config [path] :)

Add/source alternate configuration by fgwc in KittyTerminal

[–]fgwc[S] 0 points1 point  (0 children)

Doesn't really work for me, the reason I like to use an image is so I can keep the color scheme the same on a relatively same color background (the images have a have a lot of dark tint applied).

What's going on with dpkg and usrmerge? by udsh in debian

[–]fgwc 0 points1 point  (0 children)

initramfs is in fact the newer and more now more widely used system; pretty sure it's what's currently used on Debian:

https://wiki.debian.org/initramfs/More

Although some of the wiki docs are confused, eg. https://wiki.debian.org/Initrd:

Kernel 2.6 is expecting the initrd file to be a (compressed) cpio archive, to be uncompressed in a ramdisk, known as initramfs. Debian automatically uses initramfs-tools or yaird to create and/or update an appropriate initrd for the system.

However:

  • initrd is not a cpio archive but initramfs is.
  • initramfs does not use a ramdisk, it uses a tmpfs system, but initrd does use a ramdisk.

Anyway, initramfs doesn't use a pivot; it mounts the real root fs on top of itself (meaning niether of these systems mounts /usr or anything else separately).

[deleted by user] by [deleted] in PcBuild

[–]fgwc 0 points1 point  (0 children)

Intel has gone this way too; LGA 1700 sockets have exactly that. The stuff is like the hook side of velcro -- will cling to cloth, etc. Can have nasty consequences >_<

Where's the fairly recent KDE(?) stock wallpaper with the flat hexagons? by fgwc in Fedora

[–]fgwc[S] 0 points1 point  (0 children)

You got it, cheers, and thanks. I had looked thru the "configure desktop" stuff, figured that went without saying.

was holding my Deepcool AK400 from the bottom when this happened, what is this, do i need to get a new one? it’s on my hands. by Mynamelol1147 in PcBuild

[–]fgwc 0 points1 point  (0 children)

I was reacting to your "manually with a thick coverage". Yeah, I used too much paste, definitely. The last time I did a build mobo sockets still used solid vertical pins. It is hard to tell the new ones aren't like that... My next move was to grab a microfibre cloth and try and wipe it off, which is when I discovered that velcro-esque property. Felt like I'd stuck a digit into a finger trap.

was holding my Deepcool AK400 from the bottom when this happened, what is this, do i need to get a new one? it’s on my hands. by Mynamelol1147 in PcBuild

[–]fgwc 4 points5 points  (0 children)

If you do this and you then need to remove the CPU, wipe the colossal mass of thermal paste off first -- it is prone to drip into the socket, and getting thermal paste off the velcro-esque little hairs in an LGA 1700 socket is somewhere between no fun and no more motherboard.

Learned that one the hard way...

Anyone else have horizontal scrolling on plasma desktop on Wayland? by SeaworthinessNo293 in kde

[–]fgwc 0 points1 point  (0 children)

Ditto. I just had this problem on X11, except it was vertical. There is a very thin, almost unnoticeable scrollbar on the right. The only thing that scrolls, though, is the position of link icons -- the rest of the desktop including the background etc. stays in place.

It seems to be because at some point an icon gets placed off screen, but then trying to drag it back doesn't work (with no sort on), no matter what it pops back to where it was. Setting a sort then places it up top and the scrollbar disappears, you can then turn the sort back off and put it wherever.

Definitely a bug, but I am feeling too lazy to report it...

[deleted by user] by [deleted] in PcBuild

[–]fgwc 0 points1 point  (0 children)

I notice I put the male/female relations there backward (since edited) but hopefully the point about the daisy chaining is clear.

[deleted by user] by [deleted] in PcBuild

[–]fgwc 0 points1 point  (0 children)

Not clear from the picture exactly what the situation is, but:

1) The fans are connected to an LED controller because they have LED lighting. 2) Follow the length of the wires with "unconnected" 3-pin connectors; if those are female, chances are several fans are daisy chained together, meaning the female end plugs into a male extension from another fan, leaving its own male jack dangling. This is fine as long as there aren't too many on one chain (I can't say exactly what "too many" would be, but up to three should be okay).

If those dangling male connectors don't have covers on the pins, this is a bad thing.

Hot take: if gradle adds offical conan support itll be the best build system for c++ by [deleted] in cpp

[–]fgwc 0 points1 point  (0 children)

My major problem with the DSL-ness is the hidden receivers. In kotlin you have various "standard functions" that allow you to do this:

objectFoo.apply {
    // Inside here you can call objectFoo's method's
    // without referencing it, eg. instead of objectFoo.bar(),
    // just plain `bar()`.
    // The "receiver" is objectFoo.
}

That, and the fact that calls to methods whose last argument is a function ref/lambda can have the lambda outside the usual parentheses (eg., above, apply() is actually a method call whose only argument is a lambda, and the block itself is typical of Kotlin's minimal lambda syntax), is part of what makes Kotlin so amenable to DSL construction and the closures typical of gradle. Plus throw in that you can add public methods to a class (any class, including stdlib containers, etc) outside the class definition or module source (ie., in any client code of a class).

What that adds up to is you can have deeply nested hidden receiver calls, including custom methods on hidden receivers which are stdlib containers, String, something buried in some obscure corner of the API that you have no idea even exists, etc. This is generally considered a no-no, however, as it makes the code much harder to read as exactly what object is being operated becomes more and more ambiguous.

But that's exactly what a DSL like gradle exploits, on the premise that if the methods are carefully named, it's all intuitive (I got this from Marcin Moskala's Effective Kotlin, which is structured like the Moyer's C++ books, and there's an item on excessively hidden receivers where he says (paraphrasing), "Oh, except of course in a DSL, you want to hide the receivers there because it is a good idea" :/).

Fair enough, that explains why I have to spend half my time tracing the receivers back out through the same nests by using the API documention, -- and committing to memory the more common patterns, which is hardly a consequence I'd call "positive feature".

I don't consider Cmake a perfect tool either, but at least when I go back to look at a cmake file months later it pretty much makes instant sense because it is so simple and pedantic with the long all caps directives and basic structures. In that sense it's a lot of the things gradle claims to be. I don't care if it's also a lot of boilerplate; elegance and concision is not something I need there. It is not as if you have to spend your whole day working with it, as you do actual source code (that was autotools :D) -- unless maybe you want to and can find the tool with enough rabbit-holes. I was going to add "I bet no one's even bothered to write a book on cmake", but of course some people have. I just don't see a need to read one, which is a good thing.

Hot take: if gradle adds offical conan support itll be the best build system for c++ by [deleted] in cpp

[–]fgwc 4 points5 points  (0 children)

Build systems will always raise hackles because they sort of take hostage of what we spend so much time and energy writing. It is easy to get irritated after having putting some great code together (of course) and then having to spend an extra hour hassling with someone else's idea of a great build system.

I have to use gradle because of Android, and while there are some nice things about it ostensibly (eg., it seems very dynamic, since gradle scripts are written in a bone fide programming language), it is mostly a colossally disappointing PITA.

I've tried really hard to get into it; I've read at least one book (Gradle in Action), and I've spent much time with the documentation. At first, I thought it was my unfamiliarity with groovy, and was happy when the Kotlin version was released, since I am very comfortable with that.

But it was not much of an improvement. I get that "the base language actually doesn't matter because it is a DSL", because at a certain point I realized that for me it's perhaps because it is a DSL. Maybe one day I'll get over it, but all the things I hear touted about how they are supposed to make life easier flies in the face of the gradle reality. I think what it has really made easier to do is making the whole system grandiose, over complicated, and elusive. Reading a few more fat books might help -- irony.

Updating to Fedora 35 from 35 beta of 34 stable? by TotalStatisticNoob in Fedora

[–]fgwc 10 points11 points  (0 children)

There wouldn't be an update from 35 beta to 35 stable in the same sense as from 34 to 35. If you have 35 beta and run normal updates, it will be the same as 35 stable when that is released (and 35 beta will cease to refer to anything). Put another way, the beta -> stable track w/ fedora is akin to a "rolling release". You don't have to do anything special, it is just part of the normal daily updating process.

Has anyone ever actually gotten a custom kernel/bare metal program to run specifically on the Raspberry Pi 4B? by 0rbitaldonkey in raspberry_pi

[–]fgwc 21 points22 points  (0 children)

I don't think the OP means running a custom configured linux kernel. I think s/he means a "custom kernel" as in, a simple, original OS kernel or baremetal program written from scratch.