Linux: Don't get me started on “executives” | Hacker News Reader

Linux: Don't get me started on “executives”

lore.kernel.org

97 pointscassepipe40 comments

Interestingly, non-profits tend to have the same problem with general fund funding. People will donate food or buildings (which is great), but it is actually hard to get money to pay the utilities. In-kind on grants helps but is often shrunk for reasons of "getting more money to do the objective".

Paying technical debt or utilities is not sexy and a lot of people want their name attached to cool new things not keeping the lights on.

I run a nonprofit and we have a policy that we only accept unrestricted funds to allow us to operate at maximum efficiency and impact. There is a large and not often talked about principle agent problem that restricted donations create, in addition to the additional overhead.

We make our finances 100% transparent so the people we serve, donors, and the public can hold us accountable. Our open finances are at https://bank.hackclub.com/hq/.

Main homepage at https://hackclub.com / open source at https://github.com/hackclub/hackclub

This is a great way to go when you have a very narrow scope as it seems you have here (well done btw). The downside for groups with wider scopes is turning away money if the donor isn't comfortable with this. Even a hackerspace may have this problem. A donor may wish to sponsor some improvements to the metal shop, but if they don't restrict the donation for the metal shop, then some delay occurs, new board is elected, etc, then suddenly those funds get lost in the shuffle and money gets spent on the wood shop instead. It does keep a non-profit honest, but unfortunately yea it comes with overhead of tracking the funds and ensuring they get routed correctly.

Just want to say that Hackclub is an awesome idea. Nice work!

This is a such an understated problem with non-profits and charities. In the UK (not sure about other countries) it's pretty common for people to give money to a charity which is ring-fenced for a particular thing. Legally the charity then can't use that money for anything else. No one wants to fund the general running of a charity, they'd rather fund a specific event or programme. That causes so much overhead on accounting to ensure those funds go to the right projects and figuring out how to pay the water and electric bills. People don't realise that it actually costs more money on accounting to give ring-fenced money like that. I imagine similar is true towards things like the linux kernel with development efforts.

You inevitably need to fundraise for something, because it's the emotive stuff that helps you fundraise. You can be careful about your fundraising though to make sure that it isn't quite as restrictive as it needs to be.

My favourite story here is "Scrunchy the cat". Scrunchy was a cat in one of the UK cat charities (Cat's Protection?) who needed a hip operation. Management were very clear "if you raise money for this, make sure it's not restricted to just Scrunchy". Inevitably the fund raisers ignored this completely and ended up raising enough money for Scrunchy to have 20 hip operations and the money couldn't be used for anything else. Scrunchy had her hip operation, and then for a few years afterwards any cat in the Cat's Protection who needed the same operation was renamed Scrunchy!

Seconding this. However I do appreciate the chicken-and-egg problem donors have here as they can get tricked into throwing money at a non-sustainable project if it's not already on steady-enough-legs to cover the non-sexy things that need money to operate. They might not be able to tell how much follow-through the organization really has or if it's just all fluff that will waste a bunch of their donated funds if the project goes under prematurely.

But it's so frustrating to get a non-profit started and need funds to move forwards with the mission but donors don't want to fund the critical stuff like utilities. But hey, they still "love your mission". I also appreciate they usually want to make single donations rather than letting an organization get hooked on a steady stream of donations, it helps keep the org from getting stagnate. And segregating restricted and non-restricted funds is an extra chore on the already taxed treasurer has to look forward too.

The fact is: It's not our money.

Oh for sure, I can spend millions of dollars just by saying I believe it will deliver tens more to the company. If I'm right, I'll get a fat bonus, and if I'm wrong (too much), they'll fire me.

But If I say we need to send millions of dollars or else we'll run into an amorphous risk that might make us look bad, how possibly can the board evaluate my claim?

Or put another way, if I said I had a tiger-detecting t-shirt that made noise when a tiger about to strike, would you believe me?

It is really hard to invest in something that benefits anyone other than the company, and harder still if it benefits someone else more. Basically it needs to be your money, or clearly cost-of-sales to make that kind of decision, so while I think I can empathise with the rant, I'm not sure what I (or any executive, really) could do about it.

This probably needs a better title (currently— Linux: Dont get me started on “executives”). Maybe, “Linux Needs Executives to Increase Priority of Bugfix Development”. As it stands the title doesn’t give the reader much of a clue about what the post is about.

Ooops. I thought editorializing was bad so I just reposted the link as I saw it on tuxrurls.com and added Linux in front of it to give context. I agree it would have deserved a better title. My bad.

This is the case for pretty much every open source project. See eg. Openssl.

Since open source can be used for free, there is very little incentive to change the current situation. And with non copy left licences it can be even worse. The only realistic way to fix these problems I can imagine is to force companies to use paid distros, and let these companies hire developers.

But it has been historically hard to make people pay for distro support. Red Hat and Suse were successful, but they never got big enough. It's too easy to use their products for free, or use alternatives like Debian.

I am in the same situation. The features were implemented and all the executives were happy. Now the product reached the customers and all I do is support and bug fixing instead of implementing nice-to-have things. Executives love to ignore all costs during the whole product lifecycle. I am not surprised here at all.

I run into this problem all the time at my work. The company loves to fund new solutions to our problems, but those solutions never pay out because the company has no plan or funding to maintain the solution once the MVP has been developed and released. Our process is built on a pile of abandonware.

In my experience the executives want what the sales folks want. What the sales folks want is features, preferably features that work half the time so they can include a support contract on top of the license. So they can fix bugs and get paid for it but only the ones for a specific paying customer. They don't care if the overall thing is dying for lack of investment, they just want a signing because that's what their bonus is based off of.

In PostgreSQL community, the most successful patches follow a pattern sorta like this:

* Email the hackers list about intentions, ensure you aren't overlooking obvious things. The more core maintainers know and understand what you're doing the more likely you are to be met with critical support. (Hopefully this part is obvious!)

* Code patch: Prepare the work surface: clean up, refactor, debug, extend, whatever it takes to facilitate easy integration of upcoming feature patches, but preserves existing functionality. The code is internally pretty clean but not necessarily primed to go the direction you want.

* Code patches: Plan diffs for human review and validation: Scope and volume matter! Your additions join existing development; plan to maintain your additions against a moving codebase throughout the integration process.

And the more I think about what I wrote, I don't think it scales to the kernel. I'd love to be wrong.

As a non-native speaker, I always found the term "executive" for managers somewhat strange. Why call someone who doesn't actually execute anything "executive"?

The label is used as a parallel to the "executive functions" of the brain. This layer control the behavior of the overall organism: it selects goals, and monitors behaviors required to attain those goals. This describes the intended role of (upper) management inside a complex interdependent organism that is a business with 1,000+ independent brains working on it.

An executive isn't the same as a manager, but decide what the business shall do (and then do it/execute it; usually this means hiring people though). They are accountable only to the owners of the business and legislation (and maybe only the latter if they are also the owner). An executive doesn't have to be a manager, for example the programming CTO who has no employees and writes all the code themselves. A manager can also be an executive, for example the CEO who manages their direct reports. A manager might not be an executive, for example, if their boss is another manager

It's managers all the way down.

Sometimes yes: If those managers are managing vendors (or other business relationships).

Confusingly some companies use "executive" to refer to their lowest positions, since they "do" as well. I hope it's clear I'm not talking about that.

My interpretation is that these are the group of people who "execute" the will of the board. The board are the ones who set the direction of the company, but then the Executive Officers of the company are the ones who execute that.

Ah, you are missing the key thought that they do the execution by getting all the cogs in the machine to move.

It’s quite possible that they move the cogs in opposing directions, jamming up the machine.

Sadly, that seems to happen more often than it should. They also remove cogs for no reason.

There is probably some explanation, but I don’t think the etymology is any more transparent to native speakers than it is to you. It’s just one of those words whose meaning has drifted over time.

The modern sense of executive seems to be originally a US thing related to the executive branch of government. Which does indeed carry out laws and policies but also, especially in more modern times, is the branch of government that's most "in charge."

I'm not a kernel developer so I don't understand the details of this part:

>People forget that only a few years ago have we decided that the kernel now has to protect userspace programs from malicious hardware. That's a major shift in thinking, now data that we used to blindly trust can not be trusted at all.

How come this wasn't being done already? Wouldn't you want drivers to do safety checks on everything, in case of a hardware failure? Or does this refer to something else, besides safety checks?

If you blindly trust hardware then on potential attack vector is malicious hardware. This used to be known as the Evil Maid attack. If a bad actor get's access to your hardware the thinking goes then all bets are off. And what happens when a significant portion of your hardware is built in a country known to be a bad actor? Well maybe the kernel should start treating the hardware as potential attack vectors now.

A seat belt is a safety feature, while bullet-proof glass is a security feature. The major shift in thinking was that the kernel needed to start adding bullet-proof glass rather than better seat belts.

I don't think I understand that analogy in terms of kernel code, can you give an example of what seat belts and bullet proof glass are in this context? Does that mean that previously in places where they only had CRCs, they added firewalling and cryptographic signing?

A way to detect buffer overflows is by using canary values at the end of the buffer. A hardware failure is unlikely to randomly generate the same value as the canary and you can use this to detect an overflow. Malicious hardware would want to deliberately set the canary to the same value as it was before so as to escape detection, and you need to use something more sophisticated like a random canary value instead of a constant.

Previously, if a USB device was plugged in it then it might work or it might not work and the kernel had to sanely handle both of those cases. The shift is that now the kernel has to handle that USB device actively trying to do something nefarious.

Designing code to be resistant to active malicious attack is very different than just handling error cases for things that don't work.

Probably due to the rise in cloud. Where people run software on hardware which is totally abstracted away from the end consumer.

> Or does this refer to something else, besides safety checks?

I think it largely refers to the Spectre + Meltdown class of attacks, which caused the kernel to introduce a whole class of fixes (retpolines, etc.).

Spectre and Meltdown are (presumably) not malicious hardware, they're hardware bugs that enable malicious software.

Hmm, I think you're probably right, and I was overthinking it, thanks :)

Malicious and failed at not the same thing.

So does that mean there is a significant difference between, for example, a malicious USB device versus a damaged USB device, from the kernel point of view? It seems that both would be sending incorrect data that the kernel should catch, right?

damaged device - sends some random data and prevents link from working, could cause BSOD

malicious device - will send dma requests to read memory and then to send it to some other server or will implant some malicious software in memory or inside other devices.

Reply on news.ycombinator.com