How Executive Compensation is Like the Weather - <AUTHOR> http://business.theatlantic.com/2009/06/how_executive_compensation_is_like_the_weather.php

<comment><USER2> Wow, that's a load of crap.

You can link a traders pay to what they are managing not just what the firm's overall position. The obvious solution would link 90% of their pay to the preformance of what they manage such that losing money results in a reductin in pay beyound what breaking even does. AKA lose all of our money and you make nothing over the last 6 months.

There are reasons why nobobdy does this that have little to do with protecting investors assets.

<comment><USER3> You can only do this if the trader agrees to stay at the firm over the long term, or perhaps if he is a daytrader.

Using your scheme, a trader simply will not enter into a contract with a great chance of long term gain and short term fluctuations. Short term fluctuations may eat up his pay, even if the long term gain is guaranteed.

<comment><USER2> Plenty of people are willing to do startups for low base pay with the hope of a high reward. The real issue is you can't really beat the market just change your level of risk. So the real focus in investment banking is hiding risks in ever more creative ways.

<comment><USER3> I think you are overestimating the number of people willing to do startups.

As for beating the market, you certainly can. Plenty of people do it -- every successful startup founder, for instance.

You can also hedge risks, which is not hiding risk but paying someone else to assume them. This creates value: you focus on your core competency (your business) and someone else focuses on their core competency (managing risk).

Furthermore, even those who don't _beat_ the market are contributing to _raising the market average_. I.e., if you didn't have a bunch of people trying to beat an average market return of 4%, then the average return would be lower (e.g. 2%).

<comment><USER2> ROI decreases as more money is invested in the market.

Also as an investor, beating the market is not simply ending up with more money. I can go to Vegas with 1000$ bet on black and have a 48% chance to look like I "beat the market" but I could have also lost money. You can change the type of risk you are talking in roulette but a 90% chance of winning 1000$ involves a ~10% chance of losing 10,000$. This still sums to a negative number even if it looks like a great bet most of the time.

Investing is normally a positive return over time. But, if you are willing to lose a lot of money 5% of the time you can probably make it look like you invested well. The risk is still there, but it normally looks like you are "beating the market" even though you are just placing bets.

(This ignores actually producing a product or exploiting insider information. It also ignores scams where you take a tiny risk to lose more money than you have.)

PS: Hedging also has a cost and the net effect is a loss.

<comment><USER3> You can't ignore producing a product. The purpose of financial markets is to provide liquidity, hedging and information to people actually producing products. The financial markets tell us that GM deserves no further capital while Apple does. This increases market returns by allocating resources towards productive investments and away from bad ones.

As for ROI decreasing as more money is invested, so what? As more money is invested in the market, it chases more marginal investments. Thus, total returns / total invested goes down. What's your point?

Incidentally, hedging has a _cost_. That's not the same as saying the net effect is a loss. By that logic, all trade is a net loss due to transaction costs. Like all trade, hedging exploits comparative advantage. If I have a comparative advantage in making widgets and you have one in risk management, and our comparative advantages exceed transaction costs, we have a net gain.</comment></comment></comment></comment></comment></comment>


Most "mandatory requirements" in corporations are imaginary - <AUTHOR> https://nibblestew.blogspot.com/2020/08/most-mandatory-requirements-in.html <comment><USER2> In BigCorps, if there's a stupid requirement, there's usually a reason for the stupid requirement to be there in the first place but getting to the reason might require un-peeling a few org layers to since the people enforcing the policy will not be the people who wrote the policy. A more productive use of time would be to understand the reason for the policy, document out why it doesn't apply to your case and then attempt to get approval.

For instance, there's a restriction at my workplace (not a software company, a regular old industry fortune 500) which prevents git installs from pushing to any non corporate GitHub repo from our work machines.

The obvious reason it exists is to prevent people (a lot of who are analysts or data scientists - not professional programmers) from shooting themselves in the foot by pushing code to their personal repos in error.

It's annoying to work around if you need to say push a contribution to an open source project and you could rage at the infosec for enforcing it - but it obviously exists because stupid errors would have happened.

This principle is also called Chesterton's fence

[https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...](https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)

<comment><USER3> > but getting to the reason might require un-peeling a few org layers to since > the people enforcing the policy will not be the people who wrote the policy.

The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale. And appending "exceptions may be granted for equivalent or better processes" to requirements would also help. I was faced with a password "security policy" that pretty much only whitelisted SHA2 + salting for password hashing. We were using a time-hard (not memory-hard though) password hashing function instead and several levels of auditors were effectively asking us to downgrade to comply with their policy without even understanding the difference.

It's terribly demotivating to have to argue with people enforcing policy they do not understand and erodes any willingness to engage with those policies instead of seeing them as theater and working around them.

<comment><USER4> > The issue is that all the policy documents often only contain the One True > Way to achieve their goals, while the goals remain unstated. The documents > should always come with a rationale.

A reason can be argued against while a policy must just be followed. It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. Much like when web companies disable your account and won't say exactly why. Not gonna take the risk you prove them wrong, are they?

It would be nice though if all laws had a purpose included.

<comment><USER5> On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.

<comment><USER6> > On the other hand, a reason can convince people, while a policy can be > avoided, worked around or ignored while creating zero feelings of guilt.

Though, I'd imagine that, in many cases, adding reasons would turn a policy pamphlet into a textbook.

This seems like one of those areas where there are unavoidable tradeoffs:

* clear, concise, and rigid policies are easy to communicate and enforce, but frustrate people with better ideas.

* clear, concise, and flexible polices invite a lot of noise from people who think they know more than they do (e.g. can I use my own custom password hash I invented? It has more bits so it must be more secure.). Enforcement is also harder, since now you have to track exceptions.

* policy reasoning is harder to communicate, may never get read, and may actually discourage reading the policy.

<comment><USER5> You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. Then all of the lazy compliant people could have their brevity, and the crackpots and geniuses would both get the explanatory text they needed.

<comment><USER6> > You could have one pamphlet with the policy, and a separate book with the > reasoning, and instruct people to check the book when proposing a change or > exception.

That's still a significant trade-off: putting together a book with the reasoning would be a lot more expensive than just creating the pamphlet. Your organization might not be able to afford the cost, period, or your boss may not agree to spend all that money just to make a minority of engineers happy in a few narrow cases. Then there's the question of how many people would _actually consult_ the book of rationales; maybe it'd only be a handful.

I'm guessing most organizations tend to pursue a "minimum viable policy" tradeoff: spend as little effort as possible to create a policy that addresses a particular set of high-priority problems (since that is easily justifiable), and ignore more theoretical concerns like worker education and the personality preferences of certain kinds of individuals.

<comment><USER5> I'd explain why you're misconceiving the tradeoff, but we have a policy against omitting policy rationales, and that's that. ;)

> _Then there 's the question of how many people would actually consult the > book of rationales; maybe it'd only be a handful._

Well, it's supposed to only be a handful: the handful of people who know more than the policymaker.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> You see this in a lot of security pushback.

"I want to do X" / "I am too lazy to do Y instead" becomes "We can't do Y, it's a _mandatory_ requirement to do X"

Very high on your response agenda should always be to ask for details. Who mandated this and how? If there's a regulation, cite the exact text of the regulation. There's a good chance the person telling you it's mandatory either knows it isn't or has never actually wondered why, and you can divert them from insisting on doing X / not doing Y to an exciting journey through their bureaucracy to find out that indeed there is no such mandate and never has been.

Back when TLS 1.3 was being finalised EDCO and other groups trying to preserve RSA key exchange tried really hard to pretend that what they were doing was mandatory (it isn't and wasn't) and that their use cases were legitimate (most of them don't even appear to have a sound security rationale, let alone a legitimate _purpose_ ).

When we get to September and companies that were asleep at the wheel suddenly notice the 398 day rule (Apple unilaterally changed the maximum lifetime of new certificates in the Web PKI to 398 days starting in September) you can guarantee that some of them will insist that having longer-lived certificates is somehow mandatory.

[ Edited: It's the Enterprise Data Center Operators thus EDCO not ECDO ]

<comment><USER8> Or just in IT in general. E.g.: "We have to have a D:\ drive for applications!"

That's a rule that last made sense some time in the 90s, when it was feasible to format the system drive, reinstall windows, and then applications on a secondary drive letter would work as-is without any further steps.

In the era of 10 GB application installs that deploy several hundred system- shared components, this is a hilariously out-dated mandatory process.

Yet.

Everywhere I go. There it is: The D:\ drive with "Apps" as the volume name.

</comment></comment><comment><USER9> In 1605 there was an attempt to blow up the British Parliament during the state opening by placing explosives in the cellars. 415 years later they still search the cellars for barrels of explosives, using oil lanterns and armed with swords. I feel that so many organisations are doing the same thing, maintaining an old solution for a problem that no longer exists.

So I think it's just as, or more, important to apply this thinking to the business requirements which drive development. Half of solution architecture is asking why something is the way it is, and asking again and again until you're sure there's a real reason. A lot of the time the answer is because that's how it's always been and traces back to a technical constraint from long ago. I see this a lot with companies moving from decades old legacy systems to modern applications.

Same with processes, authorisations, security risks, etc... They tend to start when somebody mad a mistake and they stick around regardless of if they're still relevant, effective or blocking progress.

<comment><USER10> I think this is more typical in public administration. Employees just follow the existing rules/laws because it's not their job challenging them, and decision makers are mostly concerned on shifting away blame from them. Nobody wants to be that guy that ordered to stop searching for a bomb, the day that a new bomb will be placed. The only reason why one should stop doing it is to gain efficiency (= be more productive but doing less useless things), but the efficiency metric is non existent in public administrations.

<comment><USER11> I don't see what's different between public administrations and large corporations here. You say that the efficiency metric is non-existent in public administration, but it's mostly the same for many organizations within large corporations as well. Efficiency metrics may not be entirely non- existent, but they're incredibly opaque or difficult to measure. (For instance, R&D efficiency is usually difficult to measure because of the inevitable time delay between successful R&D efforts and market success.)

</comment></comment></comment><comment><USER12> This is why managers need a high level of emotional intelligence, the ability to empathize and quickly place themselves in the position of others. Without those three qualities management is ill equipped to handle these kinds of things sensibly.

Sadly the above traits are more deemed leadership qualities rather than management qualities and so often missing in management.

Leadership skills are far harder to teach than management skills and also rarer in the population than the number it management roles there are to fill.

<comment><USER13> Sorry, but this just feels like you are projecting some vague management 101 platitudes that could be applicable to any organizational problem.

I mean you're not wrong, but it's akin to saying if we all loved each other there would be no war.

I've seen plenty of great emphatic leaders get bogged down in large corps.

<comment><USER12> Not really, during my military training a there was a focus on management vs leadership and how the two intertwine.

Great leaders can be terrible managers if they don't want to do the associated admin, fortunately management skills are much easier to teach than leadership skills. Generally the latter (such as officer training) is cultivated in people that show requisite qualities (hence the UK cultivating potential military officers from 16 like the program I was in).

Neither is a given for success but the most successful people in management structure have a good mix of both to navigate. Also, I think n being empathetic doesn't always mean being nice, it just means seeing other view points and making decisions with that extra insight.

It's a fascinating topic I think.

<comment><USER14> yes, the leader/manager dichotomy is covered in mba school too, but the core curriculum usually doesn't cover it at a level of detail to be truly actionable. you have to take elective courses for that, and most students don't. the knowledge is offered, but not emphasized, unfortunately.

</comment></comment></comment></comment><comment><USER15> Aren't all rules imaginary?

> Every time someone in the management chain has axed the proposal with some > variation of "this policy can not be changed because this is our policy and > thus can not be changed", possibly with a "due to security reasons" thrown > in there somewhere.

That's circular, no doubt there. _We 've decided this rule must remain in place, because it's a rule_. This decision-making process doesn't make any sense, but I still don't see the sense in calling the rule 'imaginary'.

Is the real point here that sometimes bad rules remain in place until some external event forces a change? Doesn't sound so profound.

<comment><USER16> The management could be keeping the real reason from the contracters. It's not good for moral to say "No - cause we don't trust you".

<comment><USER17> That is usually true, hidden agendas play a big role here. In Germany similar rules about contractors are often in place to prevent outsourcing. Contractors shouldn't be too comfortable and cheap, so the workers council and union enforce such rules so their established clientele still has some advantages over the external people.

</comment></comment></comment><comment><USER18> Exact same story happened to me. I am an Indian contractor working for a US client in US. I asked for work from home in India. Customer manager said security council didn't approve it. He said something like their policy is 'don't take anything to China that you are not ok with loosing, India is one level below it, safeguard everything'. Now Corona happened and the entire team in India has been working from home for last 5 months.

Another one is AWS Workspace. I think its the same reasoning - that it is more secure and not having to deal with hardware. But that thing is horrible to use. Constantly getting Windows is on low memory, disconnections which can be recovered from only by a reboot that takes 40 minutes. Even on a good day, everything is slow, you can see the Window maximize/minimize in slow motion, run an IDE and try to debug to get 100% CPU. Join a conference call, can't even open any other Window without frustration. Once I am no longer working for this client, I want to give a piece of my mind to who ever is in charge of this.

<comment><USER19> > He said something like their policy is 'don't take anything to China that > you are not ok with loosing, India is one level below it, safeguard > everything'.

I can't imagine someone hiring a person they have such disdain for. That's a pretty sad attitude on the manager's part.

<comment><USER18> I believe he doesn't have any disdain for me (except may be for my skills). He had a meeting with the company's security council, and told me the decision afterwards. I think he just heard this line regarding trust from the council meeting. Not sure why he chose to tell me that. I would like to think he was just saying that to convey the mindset of the council people.

<comment><USER19> Ah that makes sense. I didn't necessarily think he held personal disdain, just I've noticed beyond this situation the way some people seem to treat outsourced workers worse or in a disrespectful way.

</comment></comment></comment></comment><comment> J-dawg It's interesting that in tech there is this expectation that every available thing should be done to make the employee as happy and relaxed as possible. If an employer refuses to do these things it's met with "does not compute", as in this example.

Granted, it does seem to make sense that your employees are as happy and relaxed as possible, but this attitude doesn't seem to exist in other industries to the same degree.

For example, I have a friend who works in finance. He was allowed to work from home for the bare minimum amount of time during the pandemic, his company requested him to return to the office almost as soon as the government permitted it (despite his job being possible to do 100% remotely). He also wears formal clothes every day (another thing that is frequently viewed as ridiculous in tech). But, he makes probably 3-4 times what I do per year!

It seems that in tech people expect to be "looked after" by their employer more than in other industries, yet simultaneously undervalue themselves.

Caveat: this is a perspective from the UK where finance salaries are high, and tech salaries are (as far as I can tell) much lower than the USA.

<comment><USER20> Yes there's a current trend of thinking that work should be as near play as possible.

There are entire classes of work, like digging ditches and driving equipment, that can be sweaty and rote. Not designed to be fun, but to get something done. For pay. This is becoming regarded as mentally or physically abusive.

It helps to consider the pay as recompense for whatever hardship you endure to deliver value to the employer. Which seems obvious but apparently is not.

<comment><USER21> > This is becoming regarded as mentally or physically abusive.

An acquaintance of mine working in academia told me that her boss was being bullying and abusive. I was really concerned and asked what was happening. She told me that her boss and department were making her come into the office (pre-covid) at 9am despite that she assured them she could do all her research remotely. When she would not come in or come in late, her boss was verbally reprimanding her.

This scenario is certainly bureaucratic and not the funnest, but it's funny to me that bullying is considered making people come into work at an established time.

<comment><USER22> Requiring strict adherence to arbitrary bureaucratic norms, and particularly berating someone for daring to question them, is absolutely abusive.

An awful lot of corporate culture is abusive, and designed primarily to give managers a warm fuzzy feeling of absolute control over their subordinates. Much of it derives directly from the assembly-line era, and much of the overall philosophy behind it is just thinly-veiled feudalism.

"But everyone does it this way" is _not_ a valid defense against "this behaviour is abusive and designed to squeeze the agency and will to be more than a drone out of me."

<comment><USER20> And there we differ I guess. The job is the job. Wear this; show up then; answer the phone with that phrase - its the job. Do it, and get paid. Not abuse.

<comment><USER23> Because the boss makes the rules and you should blindly follow them. The other team's boss is relaxed with these rules and the team is productive and happy but, you should still not question your boss, always put the head down and say I am sorry, always stay in late without overtime because the boss hasn't left the office yet and so on. And it doesn't matter that the boss doesn't produce anything and that you drive all the work, respect the boss because he might feel offended otherwise.

<comment><USER21> I don't think bosses should be followed blindly. But showing up and doing the job as required isn't blindly following, it's obeying.

I think the difference in what is reasonable and what is reasonable. If I question a reasonable start time "9am" that makes me someone that few want to work with. Whereas questioning forced, unpaid overtime is an entirely different, and I think reasonable question.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> Our time on this Earth is limited and we can't do everything. We have to make decisions.

"X is required" is shorthand for "we do not want to deal with the consequences of the lack of X". It's a decision. Sure, they could, but they wouldn't have resources to deal with other things.

That's basically all there is to understand here.

All the rest are corollaries:

\- Sometimes changed circumstances require revisiting some decisions. Like COVID-19. \- You can try and convince people to change their decisions. Your time to do that is limited too. Chose your battles. \- Decision fatigue exists. People may not want to make new decisions and will prefer sticking to old ones or push the burden onto other people.

Saying it's "imaginary" is childish. Sure, policies may be arbitrary, but the constraint of only having 24 hours in a day is not.

</comment><comment><USER25> Related, after telling us for years how dangerous it would be if people flew with more than 100 ml of liquid, it's now allowed (i.e. no longer dangerous?) to carry a larger quantity of hand sanitizer because of coronavirus:

[https://www.tsa.gov/news/press/releases/2020/04/15/tsas- tips...](https://www.tsa.gov/news/press/releases/2020/04/15/tsas-tips-flying- during-coronavirus-pandemic)

<comment><USER26> When circumstances change, risk profiles and trade offs change. News at 11. I mean you can rage about the unlikeliness of people concocting explosives from various liquids, but that is entirely besides the point here.

<comment> munk-a I, personally, would prefer to rage at the fact that the TSA has managed to export that liquid rule to everyone else in the world. I don't see why, when flying from Ontatio to Quebec, I need to follow the TSA's security theatre.

Though I agree that's also besides the point.

<comment><USER27> Same deal: Once the US did it, anyone else who didn't do it could now be blamed more.

Also see [https://medium.com/incerto/the-most-intolerant-wins-the- dict...](https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship- of-the-small-minority-3f1f83ce4e15)

</comment></comment></comment></comment><comment><USER28> To state a corollary of this: most "mandatory experience" on tech job requirements are imaginary.

Therefore, if you're a job seeker, and especially if you're a woman or a minority, you shouldn't let not having any of these imaginary requirements stop you from applying for whatever job you want, _especially_ if it's a junior role.

<comment><USER29> I got my first junior role by applying for a senior role. Granted, I was definitely _lucky_ they had one, but I got my foot through the senior screening tests and then realised I was in over my head.

HR was kind enough to redirect me to a newly opened junior position in another part of the company. Been with that company (directly or indirectly) for a total of 5 years now.

<comment><USER28> I wonder how often that happens. I'm guessing it happens more often than HR thinks it does. I've heard quite a few stories like yours. Usually it's from somebody who can pass all the screens but doesn't have enough years of experience to make the hiring committee feel comfortable, so they get offered a junior role that technically wasn't open and is created specifically for that person to grow in. Anyway, it's a smart move for companies that can recognise talent.

</comment></comment></comment><comment><USER30> This is one thing to try to find out when one applies for a job. What kind of stupid requirements are there and is this company prone to senseless prescriptions? Even if one thinks that a particular senseless prescription is not very burdensome to oneself it still indicates an inclination to senseless prescriptions. One should avoid such places when one looks for a job. And that actually is a risk that management is perhaps not very aware of. The people who have the most choice of places to work can just decide not to work for you if you like to push your employees around.

</comment><comment><USER31> The dynamics feel a bit like good cop / bad cop on an organisational level.

"I'd personally love to let X occur .. but it's not allowed due to company policy. This is mandatory."

I have always believed everything is negotiable in business. As people, we're subject to the rule of law, and obviously our businesses need to operate accordingly.

However, the policies that a company uses are really just a snapshot of current thinking. Nothing more than that; and thinking obviously changes.

<comment><USER32> "and thinking obviously changes"

Sometimes it doesn't - sometimes people vehemently insist on application of policies even though what they produce is ridiculous.

At a former employer I was quoted £70K (yes seventy thousand) for internal hosting of a not particularly business critical single static HTML page that would be accessed by maybe 100 people. I actually got a breakdown and it all made sense if you applied the policies the infrastructure team had invented - it didn't matter that the result was nonsense.

<comment><USER33> What does one have to do to get to such crazy numbers for a task so simple?

<comment><USER32> Well, apparently it counted as a separate application - so that required redundant (virtual servers) plus back-end databases. Add DR environment and live replication of VMs and databases, database backup retention planning, off-site storage costs. Ultra high performance SAN storage for all of that. Add pre-prod and test environments as well and it soon adds up.... apparently.

Turns out the internal infrastructure recharging model didn't scale _down_ and as it was a "process" it couldn't be changed.

</comment></comment></comment></comment><comment><USER34> I feel like I can deal with most things but "mandatory training" drives me nuts. At one company after another these are always over-produced things that impose way more distraction and time than they need to (all video/audio with little to no text transcript, stupid things like the inability to even click "next" until the unnecessary narrator finishes _reading_ you some slide, etc.). And then they have serious technical lackings like only working in certain browsers or (my favorite) having assessment tests so broken that you literally have to be careful _how_ you type something to avoid correct answers being deemed "incorrect". It's always a waste of money and time, at each job I always sent survey feedback telling them this, and no company has ever changed how they do it.

<comment> benji-york I like to turn these over-produced mandatory training exercises into speed- runs, posting my results to internal chat.

</comment></comment><comment><USER35> When someone at a company tells you policy forbids/requires something, ask who is the person setting that policy.

Policies without owners are a serious antipattern, since there's nobody to explain or refine them, or add nuance or grant exemptions.

</comment><comment><USER36> The whole problem seems to pivot around blame.

Having only ever worked at a small company, I've enjoyed the absence of fear of blame. When the hierarchy is so minimal risk-vs-benefit seems to be easy to communicate and digest between both ends of the spectrum and accept with shared responsibility. I understand this doesn't automatically scale, but it feels unsatisfying to assume blame is as inevitable part of growth.

Can anyone think of a way to avoid it? Is it a necessary side effect of larger layered hierarchy or is it something else?

<comment><USER37> I once worked for a ~10 person consulting firm. We had a contract to do some IT work for a large firm's HR department. We'd joke that the HR department needed its own HR department, to work out the politics among them. And, we'd joke that we needed clients so we could borrow their office politics so we could have some.

My pop-science (I learned about Dunbar's number from Malcom Gladwell's 'Tipping Point') theory for this is that we're wired to think of some small set of people (~150) as 'our group'/'my people', and that within that group we're more likely to forgive, and outside that group, we're more likely to blame.

</comment></comment><comment><USER38> Story colleagues told me once: requirements for a car's rear wind shield was that is had to withstand air pressures of 120km/h. But the car could not go in reverse that fast, so the requirement did not make sense and was loosened.

On delivery of the produced cars, many rear wind shields were broken. Turns out they were transported from the factory on a train, faced backwards so they could fit more cars on the train.

(no idea if this really happened, but it's a nice little story)

<comment><USER39> It certainly looks fabricated. Even if they were transported in open wagons only the front of the train feels all the power of the wind.

</comment></comment><comment><USER40> The reason contractors and consultants have silly requirements like this placed on them is because they're service providers, not employees. The managers are the customers in this arrangement, and customers often want silly things, like your physical presence in the office, because perhaps that just makes them feel better, and it's fine if some silly thing makes your customer feel better.

The broader issue he's talking about is simply the inefficiency of large organisations. There are many things that start to become much less efficient the more you scale up the size of an organisation, including risk management. This is because the feedback loops between decision and outcome starts to get much longer, the causal relationship between decision and outcome starts to become much more blurry, the distance between decision maker and impacted user gets bigger, and management starts to be comprised of less leaders and more bureaucrats.

Not only is this unavoidable, but it's a good thing. Large businesses benefit from the economies of scale, but smaller organisations get to compete with them, because smaller organisations have the potential to be orders of magnitude more efficient than large ones. It also creates market opportunities for other B2B companies to come along and address some of their efficiency issues. I've done lots of consulting and contractor work, and one of the primary factors that drives demand for my services is enterprise inefficiency. Even if you put aside any consideration for how slow they are to adapt to new technology, a lot of demand for my contracts has been driven by strict corporate salary bands. The board sets the maximum rate that an engineer is allowed to be paid, and any team in the company that requires skills that the market has priced above that rate can only access them through external contractors/consultants. I'd bet the same is true for the OP, even if they don't know it, so perhaps they shouldn't be so quick to deride enterprise inefficiency.

</comment><comment><USER41> In one of my previous jobs at a startup (~15 people), the reason for the color scheme we were forced to use on our ecommerce product wasn't the result of some marketing study or human interface recommendation, but rather the personal preference of another employee who had a "special" relationship with the company's president.

</comment><comment><USER42> The best way to deal with stupid corporate policies is to ignore them. Working remote when you're not "allowed to" is a big one to ignore, and if you don't have the access credentials you need, it might not even be possible. There are other policies that are much easier to ignore, though.

Don't like the dress code? Dress however you want. Don't think the status meeting requires your attendance? Don't go. Mandatory office hours are 9-5 but you have better things to do with your morning? Show up at 11.

What are they gonna do, fire you? Not likely. It's hard to hire people, and it's risky to fire people who perform well but flout pointless rules.

Maybe some of your coworkers will resent you for thinking you're special and the rules don't apply to you, but don't let their jealousy stop you. If your company isn't going to treat you like an adult, you don't owe them anything.

<comment><USER43> Protip: don't follow this advice. Your coworkers will resent you and you'll have a bad time.

Corporate rules can be broken, but it should always been done in a savvy way instead of a brazen way. In most orgs, your performance is less important than people's perception and opinion of you. Find a way to show them the respect and deference they crave, even if you break their rules anyway.

<comment><USER44> Being annoying and arrogant is bad performance in itself: you are producing irritation and resentment (e.g. giving the impression that rules apply to everyone else).

</comment></comment></comment><comment><USER45> I have been wondering what some of these middle managers are doing now that they aren't inventing work for themselves in the office?

It must be awfully hard to do this from home.

</comment><comment><USER46> This particular requirement that contractors cannot work from home had a purpose; so that full time employees have at least one advantage over contractors so that employees don't start asking to become contractors. Of course contractors get paid more so it makes no sense to be an employee... That's why companies need these odd rules; to artificially sweeten the worse deal... Even though there is no productivity benefit at all. It's all about exploiting psychology to keep costs down.

</comment><comment><USER47> It's all imaginary. It's just that people are in different stages of enlightenment:

 _These rules /laws are Real_

 _Wait, these rules /laws are made up/flawed_

 _The whole thing is made up_

 _Nothing is real_

 _Lets make up our own rules /laws_

 _These rules /laws have a functional place_

 _We should build process around these rules_

Every Generation washes rinses repeats forever. It doesn't matter if it's a corporate "requirement," government involvement or a scientific law, it's the same pattern.

</comment><comment><USER48> In some countries (I am from Brazil, where this is the case), consultants would be allowed to work remotely, because, if they came too often to the office and took direct orders from a manager, they'd be considered employees of the company, not of the consultancy. If you walk like an employee and quack like an employee, you have the legal rights of an employee.

</comment><comment><USER49> Once you have people in your organization, you can manipulate the internal economy of favors and perks in order to increase your ability to control their behavior.

<comment><USER50> A Gervais principle man?

<comment><USER32> Forget INTP, Sociopath|Clueless|Loser is definitely the most effective categorisation of roles in organisation I have encountered:

[https://www.ribbonfarm.com/the-gervais- principle/](https://www.ribbonfarm.com/the-gervais-principle/)

<comment><USER49> This is really interesting, thanks for sharing it! Is this how American offices actually work?

<comment><USER51> I just learned about this apparently popular interpretation and after going out and reading about it enough, I had to come back and find this thread just to say:

"I'm in this photo and I don't like it".jpg

I'm afraid it might be true! This explains a lot for me.

</comment></comment></comment></comment></comment><comment><USER52> I work in medical devices and we have a lot of that. We have tons of tedious processes that take a lot of time and don't improve the product at all. Often they prevent fixing of problems. When you ask why things are that way the answer usually is "the FDA requires it". But often when you read the latest regulations things it's easy to see ways to improve our processes and still be compliant.

I think the problem is that the company has found something that works in an acceptable manner and there is a big risk that any change will have unforeseen consequences so people stick to what works, no matter how badly.

There is another set of internal rules that clearly make life of one function easier at the expense of others. Again, these are very hard to challenge.

</comment><comment><USER53> I feel that as organization size increases, individual responsibility decreases.

At some point there's a limit where individuals become responsible for nothing and everything is a policy or process. It would be interesting to try to study or quantify this with different orgs and roles.

<comment><USER54> Funny enough i though so as well but discovered quite quickly that without this stuff, a lot of people are doing shit.

Do i think someone needs to tell me not to put every shitty tool on my work laptop which has a corp certificate? Access to vpn and corp network? With access to HyperScalers?

No.

What do my collegues? Everything. Oh there is a nice new shiny tool and it sends metrics to an external service, lets try this out...

<comment><USER55> I'm not in favour of the "BigCorp controls my entire machine" approach, but this is silly. It's not a lot of people doing shit, it's a problem of scale.

Have you verified that every single application installed on your machines sends no telemetry, no crash reporting, and has no random web servers running that run arbitrary code? It's likely that you've missed one application. Now multiply that by 10,000 employees - all it takes is one application per person, and you have a massive amount of data being leaked.

<comment><USER54> When you reach a certain scale, you will verify the tools which are running on the machines of your employees.

I'm not seeing a problem with it and my default stack is not that big: chrome, intellij, shell etc. it is reasonable and someone has to do it.

</comment></comment></comment></comment><comment><USER56> I agree with the author about how the risks are more obvious to higher ups than benefits and that is why rules generally stay the same. However, one thing that I learned as a new parent is how important it is to have consistency! I think a lot of computer engineers (ie hacker news) would enjoy an organization which tinkers with policies to find the best way to do things... But I think with a large org things need to be pretty consistent.

Now that said, I personally have bristled being in a company which wasn't flexible at all! So the key is to find a balance between consistency and flexibility, and give all levels of management and employees empowerment to find the best way to do things.

</comment><comment><USER57> Revenge culture permeates every pixel of society. Generally, the bigger or more entrenched the entity (corp, agency), the more hardened is the revenge process.

Even questioning whether revenge should be shaping our decisions is likely to be met with a measure of it.

</comment><comment><USER58> My reason for this rule would be: if you allow consultanta to work from home, how do you make sure they are not double- selling their workhours? Like they bill you 8h, but only work 4h on your project.

<comment><USER59> What stops your employees doing the same thing?

<comment><USER58> Usually you cannot work for two or more companies full time without the other finding out (at least this is what i presume)

</comment></comment></comment><comment><USER60> This article is talking specifically about corporate policy. It is good to have solid corporate policy, but not so good if it was written without proper forethought, and even worse if they do not have a mechanism to change it.

I work in this arena, in the public sector, and COVID brought massive fast changes to policy. But the public sector also already has mechanisms in place to regularly change it - regular board and city council meetings, specifically. And most organizations have a specific cadence on which they review and update their policies.

But the corporate world varies - sometimes the board sets policy, sometimes the execs, sometimes a compliance officer. Whomever it is, they need to not just write policy once and forget it - they need to treat it as a living body of documents, responsive to changes in their environment. Some companies are good at this, some are not.

I don't buy the conclusion of the article, though, that the leaders don't know enough to make decisions and policy becomes a way to entrench arbitrary rules and escape blame. Risk management and compliance are not about making life easy for the individual contributors. They are about looking at big picture risks such as litigation, regulatory compliance, and business continuity. They then set policy to be sure that well-meaning people who don't have visibility into those high-level concerns don't just make up their own rules. Yes, it puts some pain on us workers. But reduces risk. It is their job to choose those trade-offs.

That being said, not everyone is good at it, and there does need to be solid communication in the organization to let them know what problems a policy causes, so they can decide whether or not to adjust it. There also should be a communication path for people to ask why a policy exists, and start a dialogue about it.

</comment><comment><USER61> I once worked with a very talented senior artist. After a few years, he told me that he had never once submitted a time report. He felt it was needless busywork and that if he ignored managers and HR nagging about it, sooner or later they just stopped. I was horrified at the audacity and later astounded that he got away with it.

</comment><comment><USER62> This is all too common.

A friend told me about his company where the IT decision makers were largely centralised, physically near their cloud servers and they frequently discounted the measurable and serious difficulties of internal tech consumers suffered in other locations for years, even though their architecture would have made it comparatively easy to rebalance things for a more global approach.

Early in my career we were told of a major reorganization of my then company's network shares, required "Because of Compliance" \- only once it was underway and some key points still needed to be clarified did it become clear that Compliance was not even aware of the project! Nothing happened to the individual who had lied and diverted substantial resources needlessly. The individual was not even a member of the department, so saw zero benefit either.

<comment><USER63> A fun one I experienced was awful VOIP call quality due to a policy requirement that all company network traffic route through the headquarters office, and all the latency that introduced for anyone who worked from one of the (many) other offices.

Then one day the director of sales had a rather important call with a major prospective client while they happened to be visiting one of the regional offices. We were enjoying absolutely stellar-sounding phone calls within 48 hours.

</comment></comment><comment><USER64> Founders should keep this in mind anytime they are negotiating contract terms with a corporation also. There is no such thing as a "standard" contract and almost all "mandatory" clauses are not actually mandatory. This also applies to real estate transactions and almost any other high stakes negotiating. Standard and mandatory are terms used to trick inexperienced or less powerful people/entities into agreeing to terms more favorable to an opponent.

None of this means you can necessarily axe all the requirements though. It entirely depends on your negotiating position. If a company wants to work with you badly enough they'll pay their lawyer the $500 hourly to modify the contract or approve your changes.

<comment><USER65> Everyone should keep this in mind for every type of contract.

In the beginning of my adult life, I was under the expression that contracts were static and immutable. As I got more experience, I tried being more demanding (and my skills were also more in demand) when setting up contracts and I have at multiple points managed to change what was supposed to be "mandatory" and "unchangable" many times, from rental contracts to employment contracts and many other things.

</comment></comment><comment><USER66> The fact that requirements change when circumstances change DRASTICALLY doesn't mean that they were imaginary. It just means that they were based on a situation that no longer exists.

The company reacted to changing circumstances. This is how things are supposed to work.

</comment><comment><USER67> > The big question on managers' minds (either consciously or unconsciously) > when approving a policy change is "if I do this and anything goes wrong, > will I get blamed?". This should not be the basis of choice but in practice > it sadly is. This is where things go wrong. The people who would most > benefit from the change (and thus have the biggest incentive to get it > fixed) do not get to make the call. Instead it goes to people who will see > no personal benefit, only risk.

This cones very close to hitting the nail on the head but not quite. The crux of the matter is:

/Corporate risk aversion culture is only aware of the risk of change, and ignores the risk of stasis./

</comment><comment><USER68> This and other related issues to "decision makers being so very far removed from any actual work" is why I'm very happy I have never had to work for a company of more than a few hundred people. And hope I never will.

</comment><comment><USER69> OP would be better off sprinkling the occasional comma in their sentences. It is necessary in order to avoid confusion:

> Every time someone in the management chain has axed the proposal with some > variation of ...

A comma is better used after "every time"

</comment><comment><USER70> Sometimes they are not just there out of fear, but also not for your benefit. For instance at one corporation I worked for they made a policy against communicating with other departments outside of jira tickets, in order to clamp down on any union organizing that might take place. And also to prevent us from spreading rumors about an imminent wave of layoffs. Of course they said it was for "security reasons".

So I would assume malice rather than just fear of risk for any seemingly strange policy measures. The management is not your friend.

</comment><comment><USER71> A lot of these get baked into boilerplate legal agreements companies end up signing when partnering with other companies or dealing with compliance/certifications/auditors. It can cost a lot in lawyer time to go back and forth renegotiating and redlining contracts to get all these addressed (and it may not even be an option if you're a smaller business). And this is even if people impacted or implementing the requirements are even involved and suitably motivated to pushback.

</comment><comment><USER72> No rules are appeared by itself from thin air, there was always a cause. Most of the times rules are created to reduce a cognitive load. Thus changing the rules should be based on a cause greater or equal to the one prodiced the rule.

No one will change remote working rule just because of one or two outsiders' caprice (calling rule "stupid" shows just lack of understanding). World pandemy is obviously enough cause to change some rules.

</comment><comment><USER73> At least part of OP's problem is that she was a consultant. She didn't work there. Note that in her story, employees of BigCorp did WFH. There's even less upside for BigCorp to change policy because it would positively impact some consultant's work/life balance. In BigCorp's mind, the consultant is exhorbitantly expensive and doesn't deserve work/life balance anyway.

</comment><comment><USER74> Saw the exact same thing from our clients: utterly trenchant opposition to home working, then CV, lo and behold! Immediate switch to home working :D

<comment><USER75> To be fair, they probably had to choose between taking risks they previously weren't willing to take (trust in consultants should always be lower than in your own employees in my opinion) but had no choice with Covid. The last months were a matter of life or death for many companies.

And to make it clear, I love home working but I also know colleagues who work without screen protection in public places or leave their laptop unlocked when they are at home and have guests. That's potentially horrible for the company but absolutely unenforceable without physical presence.

</comment></comment><comment><USER76> Playing devil's advocate: Is it possible that, yes, of course you can work from home, and you must do that during lockdown, but is it as efficient as working in the office?

I think that's why many don't like remote: They can't see you working and they're not as comfortable video-chatting.

I'm a remote-only developer, but if I could, at any time, turn to my coworker and ask about something, I'd be more efficient.

<comment><USER77> >if I could, at any time, turn to my coworker and ask about something, I'd be more efficient

Haha, I remember when I was in the office before this all started, I had multiple coworkers who would do exactly that. I can't tell you how jarring it is to have headphones in and be in a focus state implementing something, just to have someone imagine they are able to trample on that time for their own efficiency and ask me questions. Doubly worse was they wouldn't even think thru their questions properly

Now, we're all remote, and I just hit back at their impromptu questions with "can you give me more context?" and half the time they solve it themselves. Imagine that

</comment></comment><comment><USER78> Corporate policy evolution through time: 1. given x unit of time passing, the core information that caused the assumption is forgotten or transmuted into something else. 2. given the same x unit of time passing, the context has also shifted but no tools were stated or developed to rethink the assumption.

Corporate knowledge management requires effort to be done well.

</comment><comment><USER79> This is predicated on the idea that the current situation is just as good as office work. That's debatable and even if you think WFH is strictly better there was cost in the growing pains.

Just because you think differently about a trade off it doesn't mean decisions you don't like are "imaginary."

</comment><comment><USER80> CYA has been the driving force that has allowed the species to survive this long. It's a fundamental human instinct that was selected for and reinforced through our long rough evolution on the savanna, just like pattern recognition and dominance games.

Do you really want to be the one responsible for wiping us all out?

</comment><comment><USER81> Everyone has their Labor Laws poster printed out and hanging beside their home office desk, right?

</comment><comment><USER82> I find these types of articles to be truisms.

We have some imperfect system. Everybody knows about the problems it has. Somebody writes an article about how stupid and wrong those problems are. How does that help anybody?

The real question is how you fix those problems without introducing others. Passed a certain age and work experience you start to notice that the bureaucracy that stops you from doing quick smart fixes also stops a lot of people from doing serious damage to the company.

And yes, in some cases external factors will force a quick reevaluation of that bureaucracy. And you can say "I told you so all along!". But again, that's zero value to the business. The real value is in the work done to plan and execute a change is a way that assures no collateral damage and also to satisfy humanly needs/desires in the hierarchy.

People want to cover their asses, but guess what, when you put the responsibility of a change on the smart ass that always annoys coworkers with his brilliant ideas they tend to back away from it cause his ass is precious to him too.

TLDR: [https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)

<comment><USER83> If only people were willing to place all responsibility with me. I'd happily take it if we don't have to deal with all the senseless policies/teams any more.

The bureaucracy stops idiots from being idiots. The logical solution is to not hire (or retain) idiots, not to add more bureaucracy.

<comment><USER82> From your post I think you are quite young and inexperienced. There's not enough non-idiots to run companies. Having to deal with them is a fact of business, you can't simply isolate from the world. The fact that nobody is willing to place responsibility with you should tell the same thing.

To sum it up: try to talk about what you already did. So from experience, not what you would do in your ideal world.

<comment><USER83> Considering I have worked with extremely talented and extremely stupid people I believe I know what I'm talking about (within the limits of my experience).

There seems to be absolutely zero correlation between organisational role/level and ability, instead using years of service as a proxy.

I don't really know how to fix this.

<comment><USER82> Have you managed those people you are talking about?

<comment><USER83> To some extend. Since I hired most (all?) of the people I manage I tend to believe they are less idiotic.

Or at least I'm generally in a position to do something about it.

</comment></comment></comment></comment></comment></comment><comment><USER84> I had this experience with some companies I was interviewing with. They would force me to submit my most recent payslip from my previous employer. I gave up after some protest, coz they could not have proceeded with my interviews without it.

<comment><USER85> Illegal in many other parts of the world (e.g. in Europe).

<comment><USER86> OP is probably from India, this is the norm here. Most companies will ask you for your last months of payslips, reason? Nobody knows.

In general, companies treat you are like a criminal trying to con them. Submit previous payslips, last company's relieving letter, contacting the previous company, stupid non-compete clauses, bond clauses and list goes on.

This is unlikely to change as most employees don't really have the bargaining power to question the rules, the workforce is abundant, they can just tell you to fuck off and hire someone else.

</comment></comment></comment><comment><USER87> The author explains this situation as a downside of hierarchical organizations, but what other kinds of organizations are there they can claim real experience with?

What the author is describing here is poorly designed management incentives.

</comment><comment><USER88> Many policy is tangled in initial agreements made with the local community and the Corp. For example, $$ leverage when you have large groups commuting rather working remote. The commerce wheel keeps rolling

</comment><comment><USER89> The solution to the problem: [https://en.wikipedia.org/wiki/Co- determination](https://en.wikipedia.org/wiki/Co-determination)

</comment><comment><USER90> I recommend creating your own policy, for yourself and use it similarly in situations.

It leads to fun situations and enlightening conversations when its policy versus policy.

Who says which policy is more important?

</comment><comment><USER88> Many stupid policies held by corporations generally benefit another Corp or uphold other community agreement which were often made at the beginning of operation.

</comment><comment><USER91> Another thing is consensus. If you can get buy-ins from a group of colleagues, preferably higher ranks, it'll be easier, as not a single person is to blame.

</comment><comment><USER92> Nice, yes spread the truth. All policy is negotiable. Rule by consent of the governed and all that.

</comment><comment><USER54> If i pay an external $1000 per day and that price doesn't change when they are in my office or at home, i would put them in my office for obvious security risks.

If corona means i can't get my work done, i have a new risk.

Security risk for external consultants having full access at their home vs. no one can work -> i might choose the externals giving access.

Its not imaginary.

<comment><USER93> But shouldn't you have to weigh this against the fact that a bit more freedom makes people happy?

<comment><USER17> No, because keeping external consultants happy is not the job of the company. They only have to keep their own employees happy, external consultants are seen as temporary, cheap, illoyal and taking away normal employees' jobs. Most parts of the hierarchy (except the very top) will try to inconvenience them if possible.

<comment><USER94> That doesn't seem very rational. The goal of all managers should be to maximize productivity per dollar spent. Motivated contractors who are well integrated in teams, don't need to be replaced often, and generally kept happy are far more productive, hence the bottom line of the company benefits by it.

<comment><USER17> It isn't "big picture" rational, but it is rational in a myopic way. Most managers in a company are only responsible for their own little kingdom and will care little about the rest or any overall whole-company picture. Only the highest-ups are responsible, accountable and incentivized to care about the whole.

</comment></comment></comment></comment></comment><comment><USER95> The two plots are begging to be plotted together ala Econ 101 plots

</comment><comment><USER96> I really like the graph showing "risk of blame".

</comment><comment><USER97> corps focus on keeping the status quo, little to gain from small gains, big penalty for any possible downside.

</comment><comment><USER98> Your example forgets to acknowledge that while there may have been good reasons for people to not be allowed to work remotely, COVID is a very pressing reason to do allow it, and the benefit of allowing people to work remotely vs getting absolutely nothing done or getting fined by the government for forcing people to come in is extremely obvious. So much so that the cons of allowing this have to be put aside, or remediated differently (which in some cases can even require investment).

It's a risk assessment that suddenly tilted the other way.

I don't agree with "everybody should work from the office" sentiments, myself, but I have seen this happen very clearly in many organizations.</comment>


Ask HN: Have you been able to leave Google's claws altogether? - <AUTHOR>

Here are the services I use/left:
Search: I have started using DDG a lot. Almost 90% of my searches are on DDG except for some rather specific programming or code searches that do not yield useful results.
Email: Still stuck with Google/Gmail even with my personal email. I had signed up for Google apps for my domain when there was a free version and somehow still continuing that.
Docs: Not sure if there is a reasonably competitive product out there
What other services you've been able to leave along with what I mentioned above. Are there any real alternatives? <comment><USER2> Irony that I see this question now. I did a month long migration recently to migrate away from all of my Google services to alternate services distributed among.

I started with Chrome to Firefox, followed by Gmail to Outlook, Blogger to Jekyll (i did that before), GDocs to Office Online,

Pending are those Gdrive and GoogleAnalytics which I will probably move away as soon I can find an apt alternative.

</comment><comment><USER3> For docs I like EtherCalc, Etherpad, and MediaWiki. At this point, Gmail is all I use of Google and mostly only get spam. My main email is Zimbra which I host myself. For search, I use DDG but I've been meaning to look into YaCy further. And I've not used a smartphone for a couple years now.

</comment><comment><USER4> For day-to-day stuff, it's pretty tough to beat Android's Google account integration out of the box. I don't feel a pressing need to "leave Google's claws". This question would make more sense if there was a more clearly defined, well-motivated goal.

</comment><comment><USER5> Docs: switch to Office 365

<comment><USER6> Yeah, switch to the company that has locked the world into their proprietary format for the last 2 decades.

<comment><USER2> They realized it (though its late) and slowly moving away from their Use all MS or Use none MS policy.

<comment><USER6> They only realize it when they have to because the market forces them to be open. Microsoft is not going to open up and support a good open document standard.</comment></comment></comment></comment>


Ask HN: Non-JavaScript web front end development in 2018 - <AUTHOR> What's the current state of the art for web frontend development using a better language than JavaScript?
I'm aware of Elm and Clojure as well as older efforts like GWT. I'm also aware of promising but immature efforts like GopherJS. Anything else out there that's mature and usable and that offers more than just bare bones?
I've become rather deeply disillusioned with dynamic languages and am looking for some way to get UI development back into a world where bugs can be caught at compile time and where there is some structural convention around the code. <comment><USER2> At the end of the day, all browser code boils down to javascript.

If you're looking for strict typing, I think Typescript is the most popular option.

<comment><AUTHOR> In the end it all boils down to transistor relay logic. Doesn't mean you can't have abstraction. Also WASM.

JS is fine for simpler stuff, but when you try to build something massive with a large team it gets unwieldy and bug prone.

</comment></comment><comment><USER3> There's Yesod [https://www.yesodweb.com](https://www.yesodweb.com). We use Haskell for our backend and Elm for our frontend at work, and we really enjoy Elm, but I'm very curious about Yesod and wonder if it's better.

<comment><USER4> Yesod is for the backend

</comment></comment><comment><USER5> I doubt it qualifies as the "State of the Art", but I've had good experiences with GHCjs for small projects.</comment>


Guccifer2.0: Game Over? - <AUTHOR> http://g-2.space/guccifer2_gameover.html <comment><AUTHOR> Check for yourself: [https://guccifer2.files.wordpress.com/2016/06/1.doc](https://guccifer2.files.wordpress.com/2016/06/1.doc)

Open in editor:

{\info{\title _TITLE}{\author Warren Flood} {\operator \'d4\'e5\'eb\'e8\'ea\'f1 \'dd\'e4\'ec\'f3\'ed\'e4\'ee\'e2\'e8\'f7}{\creatim\yr2016\mo6\dy15\hr13\min38}{\revtim\yr2016\mo6\dy15\hr14\min8}{\printim\yr2016\mo6\dy15\hr13\min45}

'operator' metadata tag (\'d4\'e5\'eb\'e8\'ea\'f1 \'dd\'e4\'ec\'f3\'ed\'e4\'ee\'e2\'e8\'f7) decodes to ФеликсЭдмундович (FeliksEdmundovich).

In RTF Word, 'operator' is assumed to be 'last saved by' ('revtim' half an hour later). source: [https://books.google.com.au/books?id=6iM2xNZ6dAIC&pg=PA120&l...](https://books.google.com.au/books?id=6iM2xNZ6dAIC&pg=PA120&lpg=PA120&dq=microsoft+word+%22operator%22+metadata&source=bl&ots=lm9kHk9n5Z&sig=fwQ10AtT8ShO8SbJfUpQW78o9yk&hl=en&sa=X&ved=0ahUKEwjPtpWhrITSAhXGopQKHYnnDIgQ6AEIOjAF#v=onepage&q=microsoft%20word%20%22operator%22%20metadata&f=false)

</comment><comment><USER2> What's the TL;DR? This is a huge timeline

<comment><USER3> 1) Guccifer2.0 appeared a few days after the DNC found out they had been compromised and Wikileaks announced upcoming DNC releases.

2) Nothing Guccifer2.0 personally released was either actually harmful to the DNC nor exciting.

3) Everything tying Guccifer2.0 to Russia was simple things anyone in the world could do.

4) Guccifer2.0 first document releases contain metadata showing they were modified minutes before by a tech guy who worked for democrat campaigns.

Article postulates that Guccifer2.0 was a front to discredit the real leaks that had happened and point attention to Russia.</comment></comment>


OmniFocus v Things – Mac / iPad / iPhone - <AUTHOR> http://brooksreview.net/2010/08/omnifocus-v-things-mac-ipad-iphone/ <comment><USER2> Things is nice but it really and truly does feel like development there has majorly stagnated. They are providing small, incremental updates for various features, but we've been waiting on the "coming soon" push notifications support in Things for iPhone for a year now with no real changes beyond delays.

<comment><USER3> The lack of over-the-air syncing is really a big pain! GTD apps are suppose to empty your brain of unnecessary things but I still have to remember to sync.

</comment></comment><comment><USER4> That's a lot to wade through to get to this conclusion: "There is only one way to decide which App is best for you, and that is to try both."

<comment><USER5> Yeah, I really dislike those watered down, make-everyone-happy type of review conclusions. Take a stand!

</comment></comment><comment><USER6> It's too bad Potion Factory never made the iPhone app they were talking about for The Hit List, I'm a big fan of the desktop app.

</comment><comment><USER7> I have a strange relationship with OmniFocus. I hate thinking about using it, but when I do use it I don't mind it. The Mac version is decent, but the slow startup time of the iPhone app really destroys its utility for me.

That said, after plunking down $80 for the desktop version that I use but hate thinking about, $20 for an iPhone version I never use, I just can't bring myself to spending $40 for the iPad version without being able to figure out if I'll actually use it first (I understand this is more a criticism of the App Store rules than of OmniFocus specifically).

<comment><USER8> If it helps, I've actually ditched the desktop version in favor of the iPad client, except in the limited case of moving tasks from e-mail to OF. Everything else I do on the iPad client now.

It's fantastic. Forecast view is probably one of the best things to ever happen to me.

</comment></comment><comment><USER9> If you'd rather use a webapp, I've been using Nirvana (<http://nirvanahq.com>) -- basically Things in the browser -- pretty happily for the past couple of weeks.

I was previously a Remember The Milk-er, but was never 100% satisfied with it. Nirvana suits my organizational style much better.

</comment><comment><USER10> I have owned and used pretty much every single GTD app on the market.

OmniFocus has been the winner for me simply due to its maturity. I use it in conjunction with org-mode for Emacs. org-mode is what I use for managing my code and computing environment. OmniFocus is bigger picture: "Call so-and-so @Phone"

I have to also drop my hat in the ring for TaskPaper. It's quite well done.

However, OmniFocus is unfortunate in the sense that you cannot export a flat file. It also is unfortunate how big of a behemoth the iPhone application is. I wish they'd include a standalone quick entry application so I don't have to load the entire database every single time I use the app.

</comment><comment><USER11> I just want a client that works with org-mode. I have that for iPhone, but not _quite_ for iPad or Android just yet. That's where it gets universal for me.

<comment><USER12> What do you use on the iPad?

On my iPod touch I use mobileOrg (<http://mobileorg.ncogni.to/>) with Dropbox sync and it works very well.

And using emacs+org-mode on my Mac (or Windows or *nix) machine I have all my stuff in text files (with a backup on dropbox).

And org-mode can do a lot more: Emacs Org-mode - a system for note-taking and project planning Google Tech Talks

      http://www.youtube.com/watch?v=oJTwQvgfgMM

<comment><USER11> Yeah, mobileorg is decent on the iPhone, but iPhone apps on the iPad are just useless. I basically don't do it and hope it gets updated before I get too frustrated and try to get involved. :)</comment></comment></comment>


Massmodz.com founder arrested by FBI - <AUTHOR> http://www.itworld.com/security/94694/fbi-arrests-alleged-cable-modem-hacker

<comment><USER2> He posted the videos to YouTube? How can someone possibly be smart enough to hack a cable modem to spoof its MAC address, while simultaneously being boneheaded enough to post fraud instructions on YouTube? Shenanigans!</comment>


Robustness, the forgotten code quality - <AUTHOR> http://www.makinggoodsoftware.com/2010/03/02/robustness-the-forgotten-code-quality/

<comment><USER2> He makes a good point... But then ignores the most important part of robustness: good exception handling. Most of the issues he mentions are more related to maintainability issues than robustness.</comment>


When a Human Liver Is Supercooled to -4 C - <AUTHOR> https://www.theatlantic.com/science/archive/2019/09/when-human-liver-supercooled/597637/ <comment><USER2> Supercooled = 14 degrees warmer than a household freezer?

<comment><USER3> See [https://en.m.wikipedia.org/wiki/Supercooling](https://en.m.wikipedia.org/wiki/Supercooling)

<comment><USER2> Ah right. Thanks for pointing that out.</comment></comment></comment>


The Updated Draft Design for Go 2 Contracts - <AUTHOR> https://go.googlesource.com/proposal/+/4a54a00950b56dd0096482d0edae46969d7432a6/design/go2draft-contracts.md <comment><USER2> Why are these called "contracts"? It's just another generic type mechanism. "Contracts" are generally associated with entry and exit conditions for functions, and are not confined to single variables. A real contract looks like:

        func foo(a integer, b integer)
        {  entry(a>b);
           ...
        }

<comment><USER3> The terminology comes from a proposal for C++ which has been under discussion for a long time.

<comment><USER4> C++ contracts are what Animats describes. Constraints and concepts are more like what's described in the article: [https://en.cppreference.com/w/cpp/language/constraints](https://en.cppreference.com/w/cpp/language/constraints)

<comment><USER2> "Contract" terminology is from Eiffel, from 1986.[1]

[1] [https://en.wikipedia.org/wiki/Design_by_contract](https://en.wikipedia.org/wiki/Design_by_contract)

</comment></comment></comment></comment><comment><USER5> Contracts seems to me like Generic interfaces in C#. Why not just call this thing "interface" [https://gist.github.com/SuddenGunter/bb105556fde9678abbd97cb...](https://gist.github.com/SuddenGunter/bb105556fde9678abbd97cb890ed6b33) instead of adding yet another keyword?

</comment><comment><USER6> I would already be more than happy if this proposal ends up in Go 2.

It looks quite sensible, and much better as the current //go: generate solution.

</comment><comment><USER7> The "no 0 value" part begs for type classes/traits, which for these Go contracts means not restricting contract functions to be methods.

      contract Zero(T) {
        Zero() T
      }

> We feel that more experience with this design is needed before deciding > what, if anything, to do here.

Hopefully the more experience leads the Go designers to solutions some production-quality languages already have to solve this :)

</comment><comment><USER8> I still don't get contracts. Can someone explain it for the slow like me?

<comment><USER9> as I understand it (and I may be misunderstanding it), contracts are exactly like interfaces, except the type of parameters/return values is left to the implementation.

So an interface of "adder" would look like:

        type adder interface {
            Add(int) int
        }

and it would only be able to support adding an int to something, and returning an int. Doing this:

        func AddStrings(a adder, b string) string {
            return a.Add(b)
        }

will break

A contract for "adder" would look like:

        contract adder(T) {
            T Add (T) T
        }

You can then use this in a function by:

        func addTheThings(type T adder)(t1, t2 T) T {
            return t1.Add(t2)
        }

which can then use any type that has an Add method

        //can't extend native types, so we have to create an alias and extend that
        type Addstring string

        func (a Addstring)Add(b Addstring) Addstring {
            return a+b
        }

        func (a Banana)Add(b Banana) Banana {
            return Banana{a.Count + b.Count}
        }

then your "addTheThings" function can operate on strings (via the Addstring type) and Bananas, and anything else that fulfills the contract. So the original example:

        func AddStrings(a adder, b string) string {
            if as,ok := a.(Addstring); ok {
                return a.Add(b)
            }
            //raise an error here
        }

On a separate note, why is "contract" becoming a keyword instead of "type foo contract {}"? Making the common business concept of "contract" a keyword is likely to break backward compatibility for some code bases

<comment><USER10> > On a separate note, why is "contract" becoming a keyword instead of "type > foo contract {}"?

I was wondering about this too. It also just feels really weird since it's a different construction than any of the other types.

Maybe the thinking is because a contract is not a type? But so what...

On first blush, it also feels weird that type is coming _before_ the type arguments, rather than after -- since types for normal arguments come after the argument.

E.g.,

        Map(T, U type)(t []T, f func(T) U) []U

feels much more consistent than

        Map(type T, U)(t []T, f func(T) U) []U

no? (Perhaps it complicates parsing, though?)

<comment><USER11> "var n int" means "in this scope, declare variable n to be if type int".

"type T adder" means "in this scope, declare T to be a type adhering to the adder contract"

<comment><USER10> Good way to think of it.</comment></comment></comment></comment></comment>


Is it normal to get hundreds of break-in attempts per day? - <AUTHOR> http://serverfault.com/questions/244614/is-it-normal-to-get-hundreds-of-break-in-attempts-per-day <comment><USER3> You can eliminate 99% of these attempted logins by changing your SSH port from the standard 22 to something else (say 2177 or whatever). Login as root (or su), open the /etc/ssh/sshd_config file and change the port number. Save your changes and restart ssh with "/etc/init.d/ssh restart" and you are good to go. You'll want to update any SSH clients you use to use the proper port (-p option on command line). Hope this helps!

<comment><USER4> Good grief I hope you never do this. Do NOT use a port > 1023 for anything that should run as root. If you do, and your machine gets compromised, any unprivileged user could start an ssh daemon, you might think, oh, why is the key different, accept it, and they've keylogged your login attempt.

<comment><USER5> I don't disagree in principle. In practice: how did they manage to start their own daemon on a port sshd is already bound to?

<comment><USER4> Web exploit, get a web shell, crash your ssh daemon somehow, start my own. Since it is running on a non-privileged port, easy enough to run my own ssh daemon there.

Crashing the ssh daemon isn't always easy, but, making the job easier for an attacker because 'obscurity' is considered a good protection scheme in this case opens up other potential vulnerabilities.

</comment></comment></comment></comment><comment><USER6> My home firewall catches 20-25 failed login attempts per day, all of which seem to originate in China. I'm tempted to setup a honeypot that'll show a fake bash prompt just to see what gets thrown at it. Naturally I assume there is an elite international force that will stop at nothing to break in and steal the larger original jpegs of my Facebook photos as well as all of my college homework. I'm on to you, elite international force!

<comment><USER7> They're likely more interested in obtaining hops from which to attack other machines.

<comment><USER8> Apparently, their appetite for the original, larger copies of photos uploaded to Facebook and for college homework knows no bounds!1!!

<comment><USER9> Why is this upvoted so highly? Am I missing some insight here?

<comment><USER10> Its called humour. Lolz were had. Enjoy.

</comment></comment></comment></comment></comment><comment><USER11> I run Rails and became tired of seeing 404s to standard ASP or PHP software (such as phpmyadmin), so I added this to our Apache conf:

RewriteRule \\.(asp|aspx|php|jsp)$ - [F,L,NC]

RewriteRule (w00tw00t) - [F,L,NC]

RewriteRule (phpmyadmin) - [F,L,NC]

RewriteRule (php-my-admin) - [F,L,NC]

That cuts off those requests before they hit a Rails process and suck up any additional resources.

<comment><USER12> On Lighty, I simply have:

        url.redirect = (
            "^(.*)php(.*)$" => "http://www.kernel.org/pub/linux/kernel/v2.6/linux-188.8.131.52.tar.bz2",
            # other stuff
        )

I do not use php on the server.. I don't know if these kits end up downloading the kernel or not, though.

<comment><USER13> Please don't do this... having bots launch a DDoS attack on kernel.org is not good.

Just throw the request away or return a 404 at the load balancer level.

If you're on Apache use mod_security, if you're not put Varnish in front and configure it to return simple 404 errors on such pages.

But don't mod_rewrite, redirect or otherwise throw traffic onto someone else's server, let alone one that will result in a traffic cost for them.

<comment> T-hawk > Please don't do this... having bots launch a DDoS attack on kernel.org is > not good.

Yeah, point them at microsoft.com instead! Should be easy to find a hefty service pack or DirectX install for the bots to hit...

<comment><USER14> Even though not all of us like Microsoft, you still shouldn't do this. The best way to handle this is to send random data at 10b/s and slow down the bots.

<comment><USER15> It'd be interesting to keep a list of the bots, and randomly redirect the traffic back at them. My first thought was that this would mess up people who unknowingly have a bot on their computer, but then I realized this might actually make them look into getting their computer fixed.

Am I missing something here, or is this actually a decent idea?

<comment><USER16> I doubt these bots can handle the redirect request. Its js and I don't see why someone would code to support it. Maybe someone better informed than me can say whether curl or wget respect redirect by default.

<comment><USER17> JS? 300 http codes cause a redirection without any JS whatsoever.

<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> I'm too lazy and too stupid to put in denyhosts or any of the other anti- guessing software, but I have put in a 7-second delay on password- authenticated SSH logins, as per <http://www.aerospacesoftware.com/howtos/ssh- kiddies.html> That makes my sshd less a honeypot and more a tarpit.

I also put in an output line so I can see what passwords they're guessing.

<comment><USER19> FWIW, denyhosts and mod-security don't seem to require any real additional configuration beyond just installing them on Ubuntu 10.10 (and copying the example config for mod-security from /usr/share/doc/mod-security- common/examples).

</comment></comment><comment><USER20> I'd say hundreds is not normal. It is order of magnitude too low.

<comment><USER21> How would you define an order of mangitude in this case?

<comment><USER22> At times, a few hundred per minute is "normal."

I prefer port knocking or two factor auth as a solution to brute force attacks. <http://code.google.com/p/google-authenticator/>

<comment><USER23> eh, disabling password auth solves the problem almost as well.

</comment></comment></comment></comment><comment><USER24> You MUST try the free and awesome configserver firewall

<http://configserver.com/cp/csf.html>

It's fantastic. Among a million other things, monitors logs for several kinds failed login attempts and can automagically ban them via iptables (with timeouts if you so desire).

 _Be sure to donate to keep this fantastic software alive if you use it._

</comment><comment><USER25> As some of the commenters on serverfault suggested, the easiest fix is to just disable password auth in sshd_config. No need to fool with denyhost's whitelisting and whatnot, just use public key auth only.

<comment><USER26> This and changing the port to something non standard is what keeps me sleeping like a baby at night.

</comment></comment><comment> mike-cardwell

      sudo apt-get install denyhosts

Job done.

<comment><USER27> Have never heard of this tool before. Is it a standard thing or is it only for the clinically paranoid?

<comment><USER28> Just because you're paranoid doesn't mean script kiddies aren't trying to root your box.

</comment></comment></comment><comment><USER29> If you're running a Rails server on Ubuntu, protecting your server is as simple as deploying your app with Moonshine, with the ssh, iptables, and denyhosts plugins.

It requires maybe 7-10 lines of configuration to have a fairly well-insulated system:

      # config/moonshine.yml
      :ssh:
      :port: 9024
      :allow_users:
        - <USER2>

      # app/manifests/application_manifest.rb
      configure({
        :denyhosts => { :admin_email => 'firstname.lastname@example.com' }
      })

      recipe :ssh
      recipe :iptables
      recipe :denyhosts

</comment><comment><USER30> Use a VPN (openvpn), and attach sshd to your VPN subnet instead of using 0.0.0.0 or your publicly routable IP. This is also great for any other services you might want to administer remotely. It's normal to bind your database/cache to 127.0.0.1, but you can also bind to an IP in your VPN subnet, which makes it a little easier than tunneling through SSH to access your database.

</comment><comment><USER31> Yes. And I'm sure it's been said: fail2ban

<comment><USER32> Denyhosts is pretty good too.

</comment></comment><comment><USER33> There are really two issues here. One is SSH and the other is HTTP.

SSH is easy. Get a static ip or figure out the ip range for your ISP. Drop any connection not in that IP range using iptables on that port. Done.

HTTP requires more creativity. It really depends on how you have things set up. I have a honeypot default vhost on Apache. If you enter just the IP address for the server, you get the honeypot. That's what most of these bots will hit. The 404 errors caused are very annoying and mess up the logs. On the honeypot, I have a RewriteRule that rewrites anything that would cause a 404 to index.html which is a blank page.

</comment><comment><USER34> I've noticed this too. Almost immediately after I signed up and created a hosting account with KnownHost, the hacking attempts started, even before I had logged in to Cpanel for the first time.

I got an automated email every time somebody failed to log in, so my iPhone was plinging every few seconds for 30 minutes before I added a filter in GMail to mark those mails as read. I've since installed fail2ban.

</comment><comment><USER35> I've got a script set up to scan my logs and temporarily ban clearly malicious IPs. It finds a few hundred new ones each day.

<comment><USER36> fail2ban does a nice job of this.

</comment></comment><comment><USER37> I have thousands attempts at my nginx server mostly from China and most of them checking for free proxy server. I am even convinced it is some sort of automatic software scanning IP ranges for proxy. Freedom is difficult in some countries.

<comment><USER37> If you see requests like: "GET <http://somesite/proxycheck.php>

Try this in Nginx server config: if ($request ~* "^[^ ]+[ ]+[^:]+://" ) { return 444; }

444 is nonstandard Nginx code that closes the connection without sending any headers.

</comment></comment><comment><USER38> For SSH break-in attempts an easier solution would be to use a random (at least alpha numeric) userid. These dictionary based attacks only use standard, most generic login ids.

<comment><USER39> No need to bother making your userid cryptographically secure; either turn off passwords or use a secure password. It doesn't matter whether the bots find a valid username, as long as they can't guess your password.

</comment></comment><comment><USER40> OSSEC (open source) is very good at blocking those. It looks at all your logs and blocks brute forces via SSH, HTTP, etc...

Link: <http://ossec.net>

</comment><comment><USER41> Yes.

Well - actually, no. Mere hundreds are kind of abnormally low.

</comment><comment><USER42> I went to look at my logs and realized I forgot both my own and root's password on my linode. Doh!

<comment><USER43> use private/public key to login!!!

<comment><USER42> I do indeed; that's why I had forgotten my password, because I always log in with my key. Amusing, this!

</comment></comment></comment><comment><USER44> I created a free test server on Windows Azure a few weeks ago with remote desktop access enabled and had failed login attempts within 2 minutes of the server going live, without publishing the ip address or dns name anywhere.</comment>


Duuble: microblogging diary - <AUTHOR> http://duuble.com

<comment><USER2> Well done on shipping. Here are some things that can be improved:

1\. Increase the font-size from 13px to 16px and set line-height 24px to make the type friendly.

2\. Increase the height of your input fields and buttons to 28px to make them easier to focus and click on.

3\. For the diary image on your front page, show a diary that has something written in it. Even better, show a screenshot of a Duuble diary.

4\. Combine "First name" and "Last name" fields into "Your Name" for better internationalization and less visual elements / tabbing.

5\. Move the "Tweet" button away from your sign up form to top right of the page. Use the official Twitter button. People are used to it.

6\. The "Read more about Duuble" button should be a link not a button.

<comment><AUTHOR> Woah, that's quite a list. Thanks though!

<comment><USER3> The "tweet" button is completely out of place, I guess some people can fill all the inputs and click on it by mistake.

<comment><USER4> Agreed about the Tweet button.

Also, consider renaming the location dropdown to "Timezone/Country", and either auto-populating it based on IP or using a "Please select item." Don't autopopulate with some obscure location where almost none of your users live.

</comment></comment></comment></comment><comment><USER5> First Impression: For some reason, unless I can see an example of exactly what this looks like / a demo I can't see myself signing up.

Signing up was fairly quick. However making my first post was a little troublesome: Hitting the "enter" button when didn't seem to post anything. The overall feel here feels less like a diary and more like a self-contained twitter feed. I think it's the atmosphere of the application that is throwing me off the most.

Congrats on shipping a product though! I'll continue to try it out.

<comment><AUTHOR> Thanks for the feedback! We'll try to add a working demo, or at least some screenshots! For the UI, we'll tweak it a bit too!

</comment></comment><comment><USER6> A communications scholar at Cornell named Lee Humphreys has a paper under review that compares Twitter to 18th century diaries. Apparently, it was common practice for people (mostly women) to keep short accounts of daily life in their journals. Every six months, they swapped the diaries with their friends and family. The Twitter of the 18th century. Old is new again.

<comment><USER7> A friend of mine found once such book from 1932. It's pretty amazing and she has fittingly been posting some of it on Tumblr: <http://someoldbooks.tumblr.com/tagged/diary>

A lot of walking down the street!

</comment></comment><comment><USER8> I think a demo is definitely needed on the homepage to convert signups.

Design wise, just be careful with using such light grey text on white background, as you can barely read some things. For example, the "bars" layout is unreadable on my screen unless you hover over a post.

</comment><comment><USER9> Interesting. I wanted to __edit __a post in order to add a tag. Unable to edit. Also, why not use the same tag format as twitter since people will be used to that.

Is there any API so I can send feeds through command-line. I already have a bash script called "whatidid" which logs to a text file and mails the file to my gmail account. I could push it to duuble.

</comment><comment><USER10> Are metal umlauts the new left out vowels for Web 2.x? Will we see "flickr" renamed to "flïckër"?

<comment><AUTHOR> Well, it's not really an 'ü', we are officially 'Duuble', not 'Düüble'. The dots above the 'u's are meant to complete the smiling faces :)

<comment><USER10> Well, I'm German. We do umlauts, we don't do smiles…

;)

</comment></comment></comment><comment><USER11> Sorry for being negative. I would say its bad design.

Why does a daily dairy site has to be like twitter? Yours is a original concept. Pour some thoughts into it and come up with original design. :)

</comment><comment><USER10> Is the lack of nicknames intentional? Sure, for a private diary I don't need to see "xxCuteHoneyPiexx" in the browser, but one might prefer to "blug" as that instead of "Deborah.Jingleheimer".

<comment><AUTHOR> Yeah, we did not really include nicknames, just first and last name. You could change your first and last name under Settings to your preferred name. If enough users want an additional option of a nickname, we could add that in the future

<comment><USER10> Considering the current Google+ brouhaha and the target demographics, I'd recommend something like that.

Also, having a bookmarklet for a pop up version of the "Just Post" page might be quite neat.

</comment></comment></comment><comment><USER12> aren't there any username? So that i can go to my blug by <http://duuble.com/username>

</comment><comment><USER13> I like lots.

</comment><comment><USER14> Scoured the front page.

Still have no idea what this is.

<comment><USER15> Is it not obvious that it is an online diary?</comment></comment>


Show HN: Header-only C++14 file for bootstrapping projects - <AUTHOR> https://github.com/robertsdotpm/h.h <comment><AUTHOR> I added a credits file just now for those concerned about authorship and GPL compatibility. Credits and copyright notices were already in the code but this should make it clearer where everything came from.</comment>


Virtual machine inspection, now with added Prolog - <AUTHOR> https://rwmj.wordpress.com/2015/12/06/inspection-now-with-added-prolog/ <comment><USER2> Awesome. Rules-based programming is one of those things that isn't useful often, but when it is it can dramatically simplify a problem. It's worth learning the basic structure of how prolog solves problems and internalizing it (ie: the four-port model).

<comment><AUTHOR> My execution model is pretty simplistic. It basically does forward chaining (not backtracking which is what a real Prolog interpreter would do). The reason is that we have the core set of true terms up front, and we can just run the rules to derive more and more terms until we hit the solution, and because of the way the rules are written, we (hopefully!) won't get a combinatorial explosion of terms.

This naive execution model is described here:

[https://github.com/rwmjones/libguestfs/blob/inspection- exper...](https://github.com/rwmjones/libguestfs/blob/inspection-expert- system/inspection/guestfs-inspection.pod)

under the section "Program evaluation".

<comment><USER3> Looks like it's more like Datalog than full Prolog. [0] You are probably using something similar to what is called the "semi-naive" evaluation strategy (which despite the disparaging-sounding name is actually pretty good).

[0] [https://en.wikipedia.org/wiki/Datalog](https://en.wikipedia.org/wiki/Datalog)

<comment><AUTHOR> Yes, I think you're right. I'm really exploring this for the first time since university, and I don't have any real formal basis for what I'm doing. Just a real world problem to solve.

</comment></comment></comment></comment><comment><USER4> Is embedding C necessary? I fear it could make the code substantially harder to read, and doesn't really give a big benefit if you are transpiring to C anyway. You could just link against a standard library.

<comment><AUTHOR> If I didn't embed C, many of the terms (eg. File, BlockDevice) would have to be "magical".</comment></comment>