kbknapp

In Rust the edge cases are often more apparent because you're often forced to at least acknowledge them. So while you do have to put thought into handling them, you don't have to spend much thought finding or worrying about missing them.

Setting KDEWM to something other than KWin no longer works in Fedora as of 35 (and other "leading edge" Plasma distros like OpenSUSE are quickly approaching this turning point as well). There are several spots in the Plasma code base that KWin is hard coded. Those distros that still allow functional KDEWM only do so because their version of Plasma is either not yet new enough to be affected, or they have deliberately held back parts of Plasma (which means at some point they'll have it give in as well).

A real attacker would try to minimize all those constraints by being collocated with the target as close as possible such as in the same datacenter or same rack if possible.

I wonder if they're talking about competing with all of systemd or not? The suite that is systemd is pretty massive, in an unironic way. I personally think one of the tragedies of systemd is how all the related tooling and components get lumped together to make it appear like an init system gone godzilla, when much of it is separate-although-related-and-consistent systems.

The lack of a CVE does not imply the lack of a security vulnerability.

Not the parent, but I've also been using KDE in a multi-monitor setup for years (I have a 1440p primary monitor, and two vertical 1080p monitors to the sides). In my experience, applications open on the primary monitor, or on the monitor that is "active" (i.e. if you run Alt+F2 to bring up a run prompt on your secondary monitor and launch an application from there, the application opens on the secondary monitor where you launched it.).

Yes, applications remember which monitor and even location on the monitor they were last at.

Same! Unfortunately we have a system is more or less tethered to use of LXD. While other workloads have moved to CentOS or Red Hat systems, LXD is supremely broken on those systems (or any distro that uses SELinux). It's extremely frustrating to be tied to Ubuntu for this one reason. It's even more frustrating when one of the key selling points from Canonical is "cross distribution!" Which appears to only be true for basic cases, or in the sense of, "Sure it's cross distro if someone other than us is willing to put in the work for their distro!"

To be clear, I'm not say you personally. I don't know you, or anything about your work so I'm speaking in purely a general sense about a position that you were representing.

I don't think all upstream contributions are in bad faith. I'm just saying there tends to be competing priorities which leads to some instances of hostility.

As for the Docker example, I don't know what the right answer is without digging deeper. My naive thought is to write a SLE/RHEL shim/plugin style component to allow functionality that's missing. This allows keeping the upstream vanilla, while not having to fork into something without the brand recognition. If that doesn't work, forking as `rhel-docker` or `sle-docker` doesn't seem that bad to me. Ubuntu does this with all the bcc-tools.

This is of course predicated on having tried all previous solutions first (paying an upstream developer, work with upstream with a good back-and-forth to incorporate a patch, etc). In the end, if the project decides something against their philosophical viewpoint, they're perfectly entitled to not accept patches. It's at that point, I think it's not the best solution to fork, downstream patch, and release as if it's the vanilla upstream.

How about using some of that revenue to pay the project maintainer to incorporate the patch upstream and make a release?

I've seen this very often in my personal experience that a company says exactly like you're saying now, "We have paying customers who demand certain patches, but the upstream project may be unable or unwilling to patch and release...so we downstream only." Alternatively, some downstream consumers simply "throw code over the wall" in the form of an upstream patch. However, those patches are sometimes duct-tape solutions which may not fit into the overall architecture/vision of the project maintainer(s). It's not fair to say, "accept this or else..." where the 'or else' is a downstream deviation (which in turn sometimes forces the upstream's hand).

The ethical way to do this work with upstream, whether it be direct compensation or more back-and-forth vice code-over-the-wall.

I think you're missing the point from the previous poster about (perceived) competition.

Unless your challenge literally stops at, "make X appear onscreen" with no regard for quality, testing, etc. Giving unchecked/unverified time restraints isn't fair. It doesn't matter you're giving more time than it should take to complete. If the task can be done in 2 hours, but you give "6" and Candidate A does it in 3, but Candidate B does it in 32 (but tells you 6) you're ranking two totally different submissions. Candidate B might have a super polished submission, while Candidate A has a baseline submission.

The poster you replied to was suggesting that tests should be either 1) not based on quality of submission and simply rely on difficulty so that only a few candidates can complete them or 2) based on quality and difficulty, but with a checked and verified time to keep the playing field level. However those options are both at odds with "low stress."

> They presented three design challenge options to pick from, with a weeks notice and advised that we should spend no more that 3–5 hours on the task (wink, wink)

I know this self-selects for people willing to do extra work for no extra compensation.

However, let me play devil's advocate for a minute as a thought experiment. I would actually worry that this issue is also a self fulfilling prophesy. If I'm told to do X in Y hours, but it takes me 10 x Y hours perhaps the employer really does expect it to take only Y hours. Maybe the typical workload at that employer is for someone who really can do X in Y. As long as that is properly compensated, I see no problem with that. If the employer is asking for an extremely high caliber developer, and will also compensate as such then it's no issue. However, an average developer applies and thus has to lie about what they can achieve in that time-frame. Let's say they get the job and then when the workload is dumped on them it obviously takes longer than the 40 hour work week and they cry about "self selecting for people willing to work extra for no compensation." When in actuality, the employer expected, based on a false presentation, that it was within the average developer's abilities.

Of course, I'm being somewhat satirical and without knowing the exact position and compensation being offered (as compared to average) no one can say if this is the case.

Those are just the protocols. They should also list the client application they're forking as well. What they're doing is like forking nginx selling you a webserver, then when people ask what it's based on they reply with 'http(s)'.

Also notice, in their "alternative graphics" none of the open source clients are listed.

> if you are making git commits through your toaster you got other issues.

This made me snort out some coffee on a Monday. Thank you!

I think your point is also a good one I don't see represented often, portability for portability's sake is kinda silly. It's use that's important.

It's pretty good, I'd recommend it. I haven't finished the book yet, but what I've read thus far has been good.

Something I'd wish I'd known (although it wouldn't have changed my decisions to purchase) is that it's not an exploration style book (i.e. "Let's cat this file and find out what it contains and why.") it's more of an explanation (i.e. "When I cat this file, it outputs XYZ which means ABC which I know from my research of the git source."). So the author isn't taking you along on their research, but rather coming back to you after the research is done to explain their findings from the ground up.

This means early chapters have a lot of, "You'll just have to trust me XYZ means ABC." But this is also understandable given the complexity of git; there isn't really a square one.

I also would have preferred the author use something like Python instead of Ruby for the reference implementation. IMO Python is a little more ubiquitous and easier to install/setup than Ruby. Ruby also leaves Windows devs at a disadvantage. But that's just me being pedantic.

Overall I'd give the thumbs up.