I never know what to write here
175 stories
·
66 followers

This Rich To Open Source

1 Comment

Reading Linus Torvalds from back at peak open source, I’m struck by how big the gap could be between what Linus had to say for himself and what seemingly everyone else wanted to say through him. Linus comes across a pretty practical guy. But Linux was having its moment. Everybody has their big idea. Tie Linux in, maybe you and your theory will be important, insightful, and revolutionary, too.

Not to be left out, Linus brought his own social insight:

Linus’s law says that all of our motivations fall into three basic categories. More important, progress is about going through those very same things as “phases” in a process of evolution, a matter of passing from one category to the next. The categories, in order, are “survival,” “social life,” and “entertainment.”

— Linus Torvalds in “What Makes Hacker’s Tick? a.k.a Linus’s Law”, prologue to Pekka Himanen’s The Hacker Ethic, 2001

Wait a minute, you might think. That’s not Linus’s Law! Linus’s Law is “given enough eyeballs, all bugs are shallow”. But that was actually Eric S. Raymond, who stuck Linus’ name on it. There were competing Linus’s Laws. Apparently Linus’s lost.

Just For Fun, which also mentions Linus’s Linus’s Law, is the book to read for the Linux origin story. But The Hacker Ethic is the one to preserve for science, the probable epitome of Dot-Com-era thought-leader theory hitching. Only the prologue’s by Linus, standing in for all of hackerdom. The epilogue’s a tie-in for a newly revised, 1,500-page academic trilogy assumingly titled The Information Age: Economy, Society and Culture. In between it’s a 153-page monograph by a fellow-Finn philosopher, arguing that hackers’ relationship to work represents a new, paradigm-busting—and thoroughly hacker-flattering—break from the Protestant Work Ethic, deep at the core of European civilization. The author’s conclusion features mock corporate board minutes for creation of the universe and a draft private contract for God’s grace, disputes in Helsinki. I shit you not.

It’s no wonder Linus’s piece was largely forgotten. But there are some choice bits of Torvaldsian bluntness to be found in it. One in particular stands out to me now:

Hacking is for rich people.

The money problem isn’t just assumed away. Its absence defines the status of hacker. In Linus’ words:

To hackers, survival is not the main thing. They’ll survive quite well on Twinkies and Jolt Cola. Seriously, by the time you have a computer on your desk, it’s not likely that your first worry is how to get the next meal or keep a roof over your head. Survival is still there as a motivational factor, but it’s not really an everyday concern to the exclusion of other motivations anymore.

And most succinctly:

A “hacker” is a person who has gone past using his computer for survival (“I bring home the bread by programming”) to the next two stages.

A hacker is rich or from a rich, generous country. Their basic material requirements are met. That leaves “social life” and “entertainment”…and a computer with which to try and get them. Peer-group cred. Technical clout. Intrinsic fulfillment. Personal creative expression. All those finer things up toward the pointy end of Maslow’s pyramid. Which is pretty clear prior art for Linus’s Law. How to scale such heights, stuck at home for a bleak, Finnish winter?

In a strict sense, hacking is not the same as open source. Workaday people occasionally do get jobs slinging code in public, on the Web. But those new to the game are often disappointed by just how much like the rest of work it is. Not much self-actualization. More reminding yourself that bills are being paid.

The story we like to hear is that the real open source, the revolutionary stuff, expresses righteous hacker frenzy, not some corporate budget allocation or mid-level management strategy. If businesses happens to be involved, it’s through odd lapses in its native authoritarianism. Occasionally a fat and happy corporation will hire good people, put them in a “lab”, allow them to release, and benignly neglect to manage them, as if by inspired mistake. The result is much the same as tenure or a particularly advanced form of the dole.

“You must be this rich to do proper hacking” is not something bread-needing coders recently tapped into the decades-running pep rally for “community-driven” open source want to hear. Especially those not from rich, generous countries, which is now most of them. The instinctive response is to quibble, pleading changed circumstances. Many people very much caught up in making rent, buying food, and supporting families have computers these days. Networked compute has been “democratized”, in the sense of more people having it. Perhaps other kinds of progress have made it unnecessary to be a single, bored rich guy to hack.

But there are blunt truths in Linus’ old amateur philosophy. People on effective sabbatical do seem more capable of turning out work different in kind from business output as usual. And having created some genuinely competitive bit of software—competitive on function, competitive on price—it takes a certain level of financial indifference, or the ignorance of one who’s never had to learn business, to give it all away. Scaled up to the organizational level, it’s a badge of structural power to dump valuable goods on the Net, confident in positioning to profit disproportionately from the market distortion.

If we accept these dynamics as frankly as Linus reflected them, even as heuristics rather than definitional laws, some clear implications for the big picture follow. Moreso than “sustainability”, those concerned with progress in software ought to think about opportunity. Software is young, and there is far more still to be unlocked than maintained. Progress isn’t just a slow march toward 100% of code conceivable now costing zero dollars and coming on an MIT License. Optimization is an ongoing tuning problem: marshal as much talent as the market can bear and push as many worthy programmers as possible past the point of subsistence, so they can advance the art. Not all worker drones. Not all gentlemen of leisure. Both, and a gap-free paved path of business models in between.

It’s generally unwise to shop at stores whose success will probably eat your job, even if they’re slightly cheaper. Ditto supporting rules or norms that will hold you down or keep you out. As programmers, we shouldn’t push absolutes, in policy or in culture, that narrow down who can make money and how.

If we pretend our only interests are as users, rather than as creators or maintainers, we don’t end up in a Utopia where no one is poor, software costs nothing, and devices never tell us no. We end up with a thin, peculiar class of people who can make it in software production, thanks-no-thanks to well remarked economic constraints. Whole categories of needs go unmet, because the kinds of people who can make a living in software either don’t see or feel those problems or can’t earn the freedom to address them with energy and focus to spare. Poor allocation of available ability keeps programming stuck in old patterns. Talent gets distributed quite without to class or nationality, but even as cheaper compute and comms make them less relevant, opportunity to realize remains stubbornly correlated.

Sounds an awful lot like where we are now.

A little blunt Linus-style economic realism could go a long way. A little less point-headed theory, too.

Read the whole story
bronzehedwick
1 day ago
reply
I really appreciate the context and history here. The economic realities of software development so often get jettisoned for a utopian dream, which does not change the economic reality for anyone other than the “dreamer”.
Jersey City, NJ
Share this story
Delete

Kimchi and Cultural Appropriation in Food.

1 Comment and 4 Shares

I waved her off. "No. We're making it on the floor like we always make it. Doing it on the table is ridiculous and no one is going to make fun of us for doing it the way it's supposed to be done."

The post Kimchi and Cultural Appropriation in Food. first appeared on The Korean Vegan.

Read the whole story
bronzehedwick
2 days ago
reply
Jersey City, NJ
angelchrys
3 days ago
reply
Overland Park, KS
jepler
3 days ago
reply
Earth, Sol system, Western spiral arm
Share this story
Delete
1 public comment
rocketo
3 days ago
reply
one of the best explanations of cultural appropriation that i've ever read.
seattle, wa

Un mot juste

1 Comment

I came across a pleasing but unusual usage of a common English word today:

“Mother was urgent that the marriage should take place soon.”

This is a somewhat archaic but perfectly valid sentence. If somebody urges something, they are urgent about it, in the same way that someone who hesitates is hesitant.

But you’ll have to have a pretty good dictionary to find references to that usage; my Concise OED only hints at it, and you have to go to a more substantial version, such as the Shorter OED, to get an actual example of it being used that way.

I know that one of the reasons you read Status-Q is to appear more erudite at evening parties, so I thought you might wish to impress your friends by adopting this turn of phrase.

It came, by the way, from Agatha Christie’s autobiography, which I’ve long considered to be one of her best books. Recommended.

Read the whole story
bronzehedwick
8 days ago
reply
Ooh! word nerd. đź“–
Jersey City, NJ
Share this story
Delete

An introduction to CSS Cascade Layers

1 Comment

It is a very exciting time for CSS authors. Long-awaited features are landing across browsers and at shocking speed. One new feature we are excited about is Cascade Layers. Cascade Layers is a new mechanism to help control when styles override others. Best of all, it is supported in all evergreen browsers so that you can use it right now!

First, let's look at the problem cascade layers intend to solve.

The problem with specificity

Cascade layers help solve the problem of specificity escalation. Specificity escalation is a problem where your styles get more and more specific, not to achieve a more narrow selection of elements but simply to override previous styles.

For example, say you have a button element that gets some styles from a framework. You need to override some of the button styles so you target its class selector.

.my-button { /* override styles */ }

Yet, your styles don't take. After investigation, you realize that the framework styled the button with two classes as part of the selector, defeating your single class's specificity.

So you style the button with two classes just to get your styles to apply.

.my-button.my-button--primary { /* override styles */ }

Later, you need to override the button again. This time, you'll need three classes in your selector or an element or ID. If you're really desperate, you throw on an !important. This can get messy quickly and lead to styles that are difficult to change.

How can cascade layers help with this problem?

A quick introduction to layers

Cascade Layers offer a method of direct control over specificity. It uses a new at-rule, @layer, to group styles in priority order.

For example, take the following button markup.

Let's say we have some styles that apply a different value to the same property.

.greetings {
  background-color: purple;
}

button {
  background-color: green;
}

Here, the button will have a purple background. The class selector .greetings takes priority over the element selector button.

We could rewrite this example using cascade layers so the button background is green.

@layer low, high;

@layer low {
  .greetings {
    background-color: purple;
  }
}

@layer high {
  button {
    background-color: green;
  }
}

The selector inside the high layer has lower specificity than the selector inside the low layer. Yet, the high layer itself takes priority over the low layer.

All browsers supporting cascade layers display them inside the dev tool panel.

A cascade layer displayed in a brower's devtools

How does this work? To find an answer, we first need to dig into what happens with specificity in the cascade without layers.

The "regular" cascade and specificity

We tend to think of specificity as selector precedence and source order.

The type of selector (e.g., an ID, class, element, etc.), and the number of selectors used, determine how much priority that style has. If there is a tie, styles that come later in the code take precedence over ones that came earlier.

Given this button markup:

The following CSS scenarios will apply style priority as indicated in the comments. 

.my-button.my-button--primary { /* … */ } /* this style applies */
.my-button { /* … */ } /* this style is overridden */
/* or… */
#submit { /* … */ } /* this style applies */
.my-button { /* … */ } /* this style is overridden */
/* or… */
.my-button { /* … */ } /* this style is overridden */
.my-button { /* … */ } /* this style applies */

If there's an inline style on an element, that will take priority over styles in your stylesheet. 


#submit { color: blue } /* the color will be red */

There are also Shadow DOM styles, author styles, and browser styles. Each of these has its own place in style priority. Yet, the specifics of each are beyond the scope of this article. See Miriam Suzanne's excellent write-up for more on this.

Now here's the important bit.

Think of each priority type as its own "bucket." A priority type could be selector specificity, inline styles, or source order. Resolving specificity involves consulting each bucket before moving on to the next.

A flowchart showing the preference for styles without cascade layers

The selector specificity bucket comes before the source order bucket. The source order bucket is only checked if the selector specificity bucket cannot determine the style's priority.

These buckets start to tell the story of how some styles can override others, all else being equal.

What does all this have to do with cascade layers? Cascade layers are their own style priority bucket. It sits below inline styles and above selector specificity and source order.

 

A flowchart showing the preference for styles with cascade layers

Let that sink in. Cascade layers happen before the browser looks at which selector types are used.

 

The Cascade layer's control is direct, unlike selectors. Selecting an ID has more specificity than selecting a class, but there is no way to select an element by class and give it more specificity than an ID. No way, that is, until now. Cascade layers give us that control.

Cascade layers code

Enough theory; let's dig into some code.

The basics

Cascade layers defined with @layer . Multiple names can be defined at once, separated by commas, and each layer has specificity precedence in the order they are defined  (in this case, left to right). Multiple @layer definitions are allowed, and their precedence is sorted in the order they are defined.

Layer names can be anything. They work best when they describe the group of styles you are encapsulating.

@layer vendor, base, components, utilities, overrides;

It's also a useful pattern to define all the layer names you'll use in your styles at the top of your stylesheet, so there is one place to see and modify the specificity order.

Defining a @layer block assigns the given styles to the named layer.

@layer vendor, base, components, utilities, overrides;

@layer base {
  * + * {
    margin-top: 1.25em;
  }
  body {
    font-size: 1.5rem;
    margin: 0 0.5em;
  }
}

Layers can also be unnamed, but only in the block form.

@layer {
  /* … */
}

Unnamed layers will have specificity in the order they were defined as normal.

Styles outside a layer will always have more priority than styles inside a layer. Styles outside layers also have more specificity than unnamed layers.

Many layer blocks

Each @layer block appends to the layered styles of the same name.

This means that the source order of the layer blocks doesn't matter. Layer blocks are always grouped by layer name. Yet, the order inside the layer block still matters. Inside a layer block, source order still applies. This includes styles appended in a later layer block.

@layer vendor, base, components, utilities, overrides;

@layer base {
  strong {
    font-weight: 900;
  }
}

/* These styles still have priority in the order defined at the top. */
@layer components {
  .my-button {
    padding: 1em;
    border: 2px solid;
    text-align: center;
  }
}

@layer base {
  /* These styles will come after the `strong` styles, inside `base`. */
  em {
    font-weight: 300;
  }
}

Unnamed layers can not be appended.

Layers and imports

Layers can also append from an @import, via the layer() function.

@import url('some-library.css') layer(libraries);

This is useful for wrapping external libraries in the layer of your choice. Notice that the layer name reference must not contain quotes.

Nested layers

Cascade layers sort of provide nesting. Think of them as sub-groups. You can use nested layers for organization, but they are still the same priority as the base layer.

Define nested layers either by placing them inside another layer or with dot syntax.

@layer components {
  @layer atoms {
    button {
      /* … */
    }
  }
}
/* or… */
@layer components.atoms {
  button {
    /* … */
  }
}

Nested layers will appear as their dot syntax versions in browser tools.

Unnamed layers

Layers can also be unnamed (sometimes called "anonymous"). Each is unique, cannot be appended to, and cannot be defined at the top.

@layer {
  /* nothing can append to this layer! */
  .fish {
    background-color: salmon;
  }
}

Source order resolves conflicts between unnamed layer blocks, as normal. Unnamed layers take priority over any named layer. Styles outside a layer still take priority over unnamed layers.

The importance of being !important

Cascade layers should remove the need for using !important as a last resort to winning the specificity war. Instead, !important can be used as it was intended. Yet, understanding its implications inside cascade layers is important (pun unfortunately intended).

Using !important on a layer style reverses the specificity. Normally, layers have increasing specificity in the order they are defined, with the earliest layer having the least specificity and the latest layer having the most. When using !important, layers have specificity in the opposite direction, with the earliest layer having the most specificity and the latest having the least. In the following example, the button will be limegreen.

@layer low, high;

@layer high {
  button {
    background-color: pink !important;
  }
}

@layer low {
  button {
    background-color: limegreen !important;
  }
}

This principle applies to the entire cascade. You can read about this in-depth in Miriam Suzanne's article.

A quick note on browser tools. At the time of this writing, the style behavior is correct in all supporting browsers. Yet, the dev tools show the wrong, higher layer taking priority.

Devtools showing the wrong priority in the Styles pane

Conclusion

We hope you have enjoyed this cascade layers exploration. Spread the word that we can lay down arms; the specificity wars are over!

 

Read the whole story
bronzehedwick
36 days ago
reply
I wrote an article on css cascade layers for lullabot!
Jersey City, NJ
Share this story
Delete

If Twitter is ending, will there be another place for people to use the news of ...

1 Comment

If Twitter is ending, will there be another place for people to use the news of a famous person’s death as the setup to a lazy joke, or is that entire art form just supposed to vanish completely?

The post appeared first on Andy Daly.

Read the whole story
bronzehedwick
37 days ago
reply
Life finds a way.
Jersey City, NJ
Share this story
Delete

Quote du jour

1 Comment

My French friend Cyril receives Status-Q updates by email, and after yesterday’s post concerning hobbies, he sent me another quote about holidays:

“Les vacances, c’est la pĂ©riode qui permet aux employĂ©s de se souvenir que les affaires peuvent continuer sans eux”. — E.J Wilson

or, roughly,

“A vacation is the time that allows employees to remember business can continue without them.”

I love this. I learned a very important lesson many years ago as the CEO of a small, fast-moving technology startup…

I think the company was only about six or seven people at the time, and we were in that classic startup mode: working mostly from a garden shed, having conversations every other day with investors or potential investors, watching the cashflow very carefully while convincing potential customers of our robust credentials and our ability to deliver.

But I wanted/needed to take a short holiday. Having gone from one startup to the next, I hadn’t had one for quite a long time and for various reasons I needed to take it now to coincide with other family plans. But I was torn: could I really leave this small team without their leader at such a critical time? What would the investors think? And so on…

In the end, I did decide to go, had a wonderful few days’ break, and came back to the office in some trepidation to see what had manage to survive my absence.

“Hello everyone!”, I said. “I’m back!”

The team looked up from their desks, puzzled for a moment, and then said, “Oh, yes, you’ve been away, haven’t you?”

It was a humbling and enlightening experience, and I’ve never forgotten it. Nobody is indispensable. Even you.

Anyway, there’s a nice twist to Cyril’s message. When I looked at it more carefully, I realised that he hadn’t just found a nice quotation to send back to me.

It was the first line of his vacation email auto-response.

Read the whole story
bronzehedwick
51 days ago
reply
This post has everything.
Jersey City, NJ
Share this story
Delete
Next Page of Stories