My Biggest Surprise: How Law Shapes the Business Landscape, and a Patent Puzzle - <AUTHOR> http://daniellefong.com/2010/02/11/how-law-shapes-the-business-landscape-and-a-patent-puzzle/ <comment><USER2> Well written, Dani, thanks.

Big companies are smarter than gov't regulators, they understand their business better, and they have a longer time horizon. So when the government comes around to regulate them, they think "OK, how can we turn this into a huge barrier to entry for new competitors?" They have large lobbyist and strategy budgets. They generally win.

The most misregulated industries in the US are energy, medical, and transportation. So there are lots of glaring inefficiencies, but they are there for a reason. Technologists assume the reason is stupidity and that clever inventions can fix things. Frustration ensues.

For your energy storage system, I suggest you target large energy consumers like manufacturing plants. Big ones have access to spot markets. Give them a system to store energy when it's cheap and deliver it to the machines during the daytime. If you can show <5 year ROI, you'll be able to sell it.

<comment><USER3> This would be my one (minor) complaint with her essay; I think that there is ample evidence in history, even fairly recent history, to refute the deregulatory undercurrent the essay has.

Regulatory oversight is certainly not perfect, or ideal, or even completely beneficial to anyone involved. Unfortunately, it is a necessary evil in any market with a combination of a large enough cost of entry _and_ a captive market in which the majority of customers can't simply opt-out altogether.

Medical insurance is a topical example that immediately comes to mind. Ten people with some resources can't start an innovative new medical insurance company; the costs are just too great. As a result, existing insurance companies have no incentive to compete in terms of price or services, and because a large enough number of people (and businesses) simply have to have insurance, they don't have to worry about their market shrinking too much.

The flap over gas prices a year ago would be another example, and before that, there was California's energy deregulation that resulted in serious problems just a few years ago.

<comment><AUTHOR> I may need to make some edits to change the tone. I am not against regulation per se, though I am against particular regulations which have perverse negative unintended consequences, as I describe. There are advantages to being in a regulatory climate, and certainly I prefer a business world ruled by law over anarchy.

I think that medical insurance here in the USA is particularly bad. Nationalization is also bad, but relatively superior, I think, lowering costs for everyone and improving care in the final analysis. Medical care, and insurance in particular, could be orders of magnitude better, but only if customers _actually care about medical insurance._ It's not exactly a treasured consumer choice. If health insurance and medical care were rolled in together, and marketed as being about healthy lifestyle choice, then you could get people to take notice. Kaiser Permanente accomplishes some of these goals, but is rather monolithic, and doesn't go far enough.

I've thought about trying to fix health insurance too. Another dramatically huge problem with huge barriers to entry. But maybe there could be a Yelp of health insurance that I could get people to care about. It was one of the 'alternative ideas' I had for that particular YC interview. Telling the partners raised the predictable eyebrows!

<comment><USER4> I also took some issue with the tone of your essay, which I found interesting overall. Though I agree with you (who wouldn't?) that regulations that have perverse unintended consequences need to be fixed, and I guess the question is how to make the framework more nimble and less vulnerable to capture by whoever is benefiting from the existing regulations.

<comment><AUTHOR> Thanks. I'll think about this.

</comment></comment></comment></comment></comment><comment><USER5> "If there's one thing I've been surprised by while trying to start startups, it's the extent to which the business landscape is shaped by law."

Yes. People who go to law school, if the law school is any good, learn about "freedom of contract" and how much that has to do with the business environment in a country. Most of the examples in this blog post are examples of regulatory restrictions on freedom of contract, and those restrictions are indeed what shape the business environment even more than natural resource disparities among countries or other things that members of the general public suppose make one country or another thrive.

</comment><comment><USER6> There's an important nugget in OP's pg rejection quote:

"...you'd spend most of your time dealing with legal and regulatory crap. That sort of work doesn't really take advantage of your skills."

The truth is, when someone figures out how to work the regulatory environment in favor of their business, they'll have a defensible competitive advantage. Accomplishing that requires a skill that is usually not found in technology people, and explains why lobbyists and lawyers make a lot of money.

<comment><USER7> Yes. This isn't a bad idea in itself; it just didn't seem a good idea for this specific group of founders. It was the same with Reddit's original plan for ordering food on cellphones. That would have been an ok idea for founders with $1m in funding and connections in the fast food business, but it wasn't such a good match for a couple college grads with (at the time) $12k in funding.

</comment></comment><comment><USER8> Dani,

That was really amazing and I learned a lot. A thought on presentation - I've got a longer attention span and more endurance than the average blog reader, I am rather completely fascinated by this topic and it's directly relevant to me, and yet I had a hard time getting through that entire post in one sitting.

It required an awful lot of thinking on one unified theme (how law shapes the business landscape), but all the examples were stand alone and thought provoking in and of themselves. I wonder if a three part series might not get more readers reading all the points, more exposure, and more knowledge spread. But that's a presentation point only, cheers for the very fascinating, incredibly well researched and presented piece. The regulation tying profits to return on capital and inability to store surplus power strikes me as particularly crazy.

<comment><AUTHOR> I was worried about this a little bit. To be honest the major problem was that I did not have time to make it shorter! I wrote this in a single sitting, starting at 9:20pm and ending after 4:00am. Near dawn. I simply wanted to get it out there...

I'll put some effort in the future to distilling the argument and contracting the post. For now, at least it's available.

<comment><USER9> I'm no expert on the best way to get readers, but I felt the article was extremely well written. It honestly felt like it belonged in a publication.

<comment><USER3> ...which is the way I (for one) would really like to see more "blogging" go, and is a large part of why I'm so vehemently against cutting up the rare essay like this one for the sake of the video game generation.

<comment><USER9> I'm with you on that. If everyone presented their opinions with as much thought and research as she has here, we'd all be a lot more informed.

</comment></comment></comment></comment></comment><comment><USER10> Part of the problem with regulated markets in the US (and not just power) is that the ingrained distaste for regulation seems to ensure that when it does happen it's done as badly and obstructively as possible.

It is possible to use regulation to create more efficient markets (such as the UK broadband market - where the distortions caused by the last-mile problem are regulated, enabling smaller players to be competitive) but I think it's only possible because people are more accepting and expectant of government intervention.

If you are willing to let the government do more, they can step in and make as many changes as they need to allow a market to function; if you are really opposed to any sort of government interference then you will only let them do the absolute minimum even if a tiny bit more intervention would make a big difference.

The flip side is that we might be more susceptible to over-regulation. CAP is a good example - although US agricultural subsidies aren't much better.

<comment><USER8> > Part of the problem with regulated markets in the US (and not just power) is > that the ingrained distaste for regulation seems to ensure that when it does > happen it's done as badly and obstructively as possible.

I'm always incredibly skeptical of the, "A little of this is going rather poorly, what we need is more of it" argument.

Actually, I've been thinking about this quite a lot lately - I've been in Taiwan and Thailand the last two months, and there's a wonderful culture of street food here. You can buy roasted peanuts or get some noodles or meat or vegetables stir-fried from a cart on the street.

We don't have this in the United States because of regulation - one particular regulation in California says you need to have a sink to wash your hands in order to sell food. Thus, no street vendors unless they have a portable sink (really, I asked a farmer's market person on this - you need a portable sink in a van to run a street market).

Now, on the surface, this is an imminently sensible regulation. Who wants to have food by someone who didn't wash their hands? But that's just the thing - _I do!_ The food is good, the vendor would be happy to sell it, I'm happy to buy it, and I darn well know the guy with the cart doesn't have the highest health standards and I make my own choices. Some street food is not up to my standards, some is.

Regulation prohibits me from making that adult decision for myself, so I'm forced into higher priced food of similar quality, or going to Taco Bell instead of getting some stir fried chicken, vegetables, and noodles.

I imagine at least one-third of regulations make sense on some level and do at least as much good as harm, but it's a little like censorship to me. It's a door you don't want to open if possible, despite the fact that there is rather nasty stuff you'd rather suppress. You'd rather suppress the bad stuff, it's probably objectively good to suppress the bad stuff, but you're always going to wind up with well-intentioned-yet-misguided people going too far. Hence, we're unable to buy street food due to the seemingly sensible regulation that no one can buy food from someone unless that person has a sink.

<comment><USER4> "I darn well know the guy with the cart doesn't have the highest health standards and I make my own choices. Some street food is not up to my standards, some is."

While that sounds good and well, how _do_ you make that choice? What are the input data that you have that makes it possible for you to make an informed choice about this?

I suspect you can't. You just have the _illusion_ of an informed choice, because you have no idea of knowing whether someone's food is full of salmonella or E Coli until _after_ the fact, when you get sick.

The key question is _why these regulations exist_. If it's because there is a significant chance of someone dying, I see nothing wrong with it. But the key is that there needs to be some dispassionate assessment of objective risk. Since at least the US population seems to be extremely risk-averse in some ways (e.g. terrorism, child abductions) but happily accepts a vastly higher risk in other situations (e.g. driving a car) the key is to not be swayed by emotions.

</comment></comment></comment><comment><USER11> Near the end, patent-avoiding strategies are discussed. Something I've wondered is of compulsory licensing. In copyrights and songwriting, there is a trio of copyright judges that determine the going rate for music in $/minute, and anyone can then reproduce music by paying that price without any negotiation. Of course, better deals can be worked out between parties, but that option is always there. Would it be possible to apply the same sort of thing to patents, to effect a positive change where one is desperately needed?

<comment><AUTHOR> It might work: I am not sure if there are any laws in existence now. It seems like it would be a hard sell since it strikes directly at organizations whose lifeblood is litigation: patent trolls.

</comment></comment><comment><USER12> [I've written about this on HN a couple times before, but it was a long time ago and I can't find it in my history.]

I designed a software program to detect skin cancer a few years ago. At the time, there were probably already a dozen such skin cancer pattern recognition programs/systems for sale. Almost all of them are/were significantly more accurate at detecting melanomas than dermatologists. I was mainly just trying to improve the accuracy of the existing software a tiny bit and to improve my programming skills. I didn't work on the hardware side of the equation at all. I didn't expect to make any money or to achieve much...I'm not too sharp as far as algorithms go and I usually coast by on marketing and domain knowledge. But, miraculously, I did eventually achieve my accuracy/consistency goals. I was unbelievably excited. I formed a small company to handle the IP for all my medical software experiments - including the skin cancer software - and I set about marketing the software to medical companies with dollar signs in my eyes. And it was one of the few times I DIDN'T run into crazy patent issues. I eventually sold the company to one of the largest engineering conglomerates in the world (to their medical division, specifically) so that I wouldn't have to deal with the regulatory crap. Being greedy, I worked out a royalty scheme on the skin cancer software in exchange for a smaller company sale price.

SERENDIPITOUS SIDE STORY: I was working on the software one day while my wife was getting ready to go to an amusement park, and I noticed she had a mole that reminded me of one of my cancer training slides. I asked her to get it biopsied. She put it off for a week or two, but I kept nagging her that I didn't like the looks of it. She went to her GP, and they told her it was fine and not to worry about it. I was pissed off, and asked her to go to a dermatologist to have it looked at. She went to a dermatologist...and was again told that it was fine and not to worry about it. I demanded she have it biopsied...to ease my mind. My wife works at the same hospital with these physicians, and she didn't want to rock the boat...but I'm very annoying when I get stuck on something. So, my wife finally had it biopsied. It comes back as a particularly nasty melanoma. She ends up having several large excisions and her lymph nodes biopsied. They eventually completely removed her axillary lymph nodes on one side (which caused some other problems), but she was extremely lucky overall. She had PET scans and other monitoring for a bit. Then they said she is completely cancer-free. They do exams every other month for her now, because she is pregnant - and pregnancy increases melanin production. Melanoma also has a large genetic component, which I didn't really know about until all of this happened. Her uncle died of the same type of melanoma yesterday. And they had told him HE was completely cancer-free about 10 months ago. This shit can keep you up at night.

My plans to move to a tropical paradise have been derailed, unfortunately, but my wife is still cancer-free.

So...in the few years since the sale I've made exactly $0 in skin cancer software royalties. It turns out the huge conglomerate bought my company for the insurance/billing stuff we had designed, not the skin cancer software. They have been largely unsuccessful in selling complete skin cancer detection systems that they already own, and don't intend to do much in that area for the foreseeable future. Most dermatologists simply don't want the software/devices, for starters.

<comment><AUTHOR> Wow, Shooter, what a story. Congratulations on writing that software, achieving your accuracy/consistency goals, and selling your company, though I share your disappointment with the fact that it never came out as a real product. It's probably difficult to sell to dermatologists something that sees what they see and does it better. That's why we were interested in the much more challenging technical environment of using software on consumer devices (like handheld cameras and cellphones).

If you have the time, I'd really like to chat some more about your experiences and your work. My friend, Adam Stein, who once worked for the FDA that I mentioned is looking for a cofounder in this area, and says that he's learned the ropes to deal with the regulatory issues.

As for the side story involving your wife, again, wow. I hear too many stories like this. Medical experts simply don't have a big enough stake in your health to be counted upon. Health is something you have to take in your own hands. I am so glad that you did.

</comment></comment><comment><USER13> Why don't you build Skin Cancer detector and sell it as Image Viewer? The end result will be someone telling the customer to go to doctor or not. It's a hack but if you are sure about the end result why not?

<comment><USER14> Possible issues:

1.) Some John Edwards ambulance chaser type finds patients who had skin cancer which was not found by the detector. He finds a doctor to say "if they came to see me, I would have spotted it."

2.) The FDA doesn't care about the disclaimer and calls it a medical device. Then you need a doctor's permission to use it.

3.) It isn't a medical device, but the FDA persuades congress to rewrite the law slightly to make it into a medical device.

Incidentally, I'm pretty sure 2 will apply, since that's the same system which applies to other medical imaging devices.

<comment><USER15> I voted up your comment; you bring up three very likely scenarios. This is a side issue, but an important one in my opinion:

Why did you mention John Edwards there? Did it really make what you were saying more clear? Or was it just a great opportunity to get in a political dig?

"""

In Artificial Intelligence, and particularly in the domain of nonmonotonic reasoning, there's a standard problem: "All Quakers are pacifists. All Republicans are not pacifists. Nixon is a Quaker and a Republican. Is Nixon a pacifist?"

What on Earth was the point of choosing this as an example? To rouse the political emotions of the readers and distract them from the main question? To make Republicans feel unwelcome in courses on Artificial Intelligence and discourage them from entering the field?

"""

<http://lesswrong.com/lw/gw/politics_is_the_mindkiller/>

<comment><USER14> At the time I was trying to personify the ambulance chaser - I had two choices, John Edwards and Lionel Hutz (a Simpson's character). I chose the real one.

However, your comment has convinced that it probably would have been better not to personify at all, since it wasn't strictly necessary and is distracting.</comment></comment></comment></comment>


Ask HN: What if a recruited senior SWE refuses to do any tech assessment? - <AUTHOR> Let's say a recruiter contacts you on LinkedIn and you're interested in the role and it genuinely looks like a good fit for you. You say you'll come in for an interview, but you won't at any point answer any technical questions beyond discussions of what you've worked on (ie no whiteboarding, no system design questions, no live coding, etc). You say your resume speaks for itself regarding your technical abilities. Do you think companies would pass on you for that? Can someone here please try it? <comment><USER2> A straight "No" to technical testing probably won't work, but you can _always_ negotiate to do something that works for both the company and yourself.

</comment><comment><USER3> I would think a senior engineer would be evaluated on system design, you don't want to show what you can do?

I wouldn't give them some basic algo questions or one of those online tests. Always start with a chat. I will turn down any "opportunity" which doesn't start with human to human interaction.

Do you know Golang and Kubernetes?

</comment><comment><USER4> Interviewed hundreds. A few have tried this. Automatic fail.

Logic is they have been coasting by on others work.

<comment><USER5> Doesn't appear there is a STEM shortage after all.</comment></comment>


CSS Utility Classes and "Separation of Concerns" (2017) - <AUTHOR> https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ <comment><USER3> I use a method called Context and Components. The idea being to build components, and to modify those components if they need to change base on context.

If I need to change the product card on my site it is at component/product- card.scss. If I want it to be different on thr homepage I change it at context/home-page.scss and I targetit with .home-page .product-card. Simple stuff, no inheritance issues either.

From my experience, reusable CSS is somewhat of a red herring. Maintainable and easily located CSS is where you get productivity gains. If you don't know what you have because there are hundreds of utility classes then what good is it.

Also, if you are using utility classes why not just inline CSS? "red-border white-background pad-20" is just as bad.

I wrote an article explaining the method here: [https://polylab.co/articles/ccm-contexts-and-components- css....](https://polylab.co/articles/ccm-contexts-and-components-css.html)

<comment><USER4> I didn't know there was a name for this method, but it's what I've settled on as well: Namespace the classes by their component's class name, and then override them, if necessary, in another namespaced context. It's pretty simple, as safe as can be expected, and works well for sites of all sizes.

The only bullet you have to bite is occasionally repeating yourself, but as you say, that part of CSS never really worked well anyway.

If using a pre-processor like Stylus or Sass, you can get a lot of composability with mixins and extensions, if that's what you want, and these can even be cleaner and more flexible than utility classes, because they can use parameters and basic logic.

<comment><USER3> > I didn't know there was a name for this method

I just made that one up when I started formalizing the method!

> The only bullet you have to bite is occasionally repeating yourself, but as > you say, that part of CSS never really worked well anyway.

I find as well that if you write clean, concise CSS that doesn't have to override anything you get away with far less CSS anyway. So repeating yourself isn't so bad. Similarly, in a project of any longevity, especially if clients are involved, chances are pretty high the things you repeated will eventually diverge. So had you made it DRY you would have to de-compose the coupled components and write it again anyway. With the Contexts, you can make most diverging modifications without ever touching the components, and I feel any more levels of inheritance than that leads to CSS that is more complex than it needs to be.

</comment></comment></comment><comment><USER5> The money quote for me:

"The reason I call the approach I take to CSS utility-first is because I try to build everything I can out of utilities, and only extract repeating patterns as they emerge."

I've been puzzling over the same "Separation of Concerns vs. Mixing Concerns" dichotomy ever since the rise of Bootstrap. Something about using Bootstrap's classes never felt right to me, but I was never happy with the amount of duplication in my traditional CSS either... I eventually settled on BEM, but that didn't 100% solve the issues either, and it seems to be getting left behind as the ecosystem gets older.

The idea of starting with the Bootstrap-like functional CSS, and then compositing repeated patterns into components, definitely seems to have tremendous upsides... Looking forward to trying this methodology out in a future project.

<comment><USER6> Two decades ago I was overjoyed to discover that Scheme was finally going to have a useful application beyond illustrating SICP and writing koans to amuse myself, because DSSSL was on the cusp of evolving into the last document styling language anyone would ever need.

Unfortunately following an incident with a broken Lisp machine, a liquid lunch, and an unlicensed particle accelerator, I became trapped in a parallel universe where the HTML ERB anointed CSS by mistake during a drunken night out in Oslo.

The fundamental concept of CSS (best revealed by H.W.Lie's thesis IMO[1]) was to create a rich and versatile and non-Turing-complete set of structural selectors in lieu of DSSSL's recursive logic, and to allow styles to overlay one another; two design choices that only by the application of gallons of irony can explain why most web pages are composed of a bunch of nested DIV elements with hashed IDs and overloaded semantic class attributes, and everyone compiles their assets into a static file.

I switched to Tailwind CSS months ago. Adam Wathan is the hero we deserve.

[1] [https://www.wiumlie.no/2006/phd/css.pdf](https://www.wiumlie.no/2006/phd/css.pdf)

<comment><USER7> As an aside, XSLT 1.0, based on DSSSL and created by its author (as is groff and SP SGML), is 20 years old to the date.

</comment></comment></comment><comment><USER8> The fundamental problem I see is that CSS is far too weak for proper separation of concerns. You can't make a nice structure in HTML, and then style it with CSS. You have to structure your HTML from the start in a way that it's feasible to style it with CSS.

(That's why every CSS question on Stack Overflow has an answer that says "use this HTML: ... and this CSS: ...". It's rarely possible to use some random HTML and style it in an arbitrary way.)

The CSS designers decided to pick a purely declarative stylesheet language, which is a cool idea and has some interesting properties. One of the things you sacrifice with this decision, though, is the ability to structure the HTML as you wish. You've got two languages you need to play with, and you've got to tweak them in concert.

There's an alternate universe where they chose to use JavaScript as the styling language. The style layer runs in its own sandbox completely separate from any other JS on your page, and all it does is accept HTML trees and lay out and style them. You can structure your HTML in any way you want, and then write 3 lines of JS to style it any way you want. You can implement TeX-style word wrapping or media queries as a library. Your designers don't have to talk to your programmers when they change something, because the HTML is generic from the start.

<comment><USER9> I agree with you that CSS is weak, especially from today's POV, and that HTML & CSS can be unwieldy together. Also that "It's rarely possible to use some random HTML and style it in an arbitrary way."

However it's not true that "can't make a nice structure in HTML, and then style it with CSS." That is one of the design goals of CSS, and it works.

In a former life I did this for many years, with many CMS and front-end systems. In a well-structured Drupal or Wordpress site, for instance, you can link to one additional stylesheet and override any aspect of the design. Some of the CSS might be ugly, and every now and then you might need the HTML tweaked to add a class, but it works.

Check out [[http://www.csszengarden.com](http://www.csszengarden.com)]. This is an old site, nearly 20 years old, put up by designer Dave Shea precisely to disprove your point :) It sports hundreds of interesting designs with non- trivial layouts, really pushing the boundaries of what was possible back in the day. All of the designs are CSS-only, and hang off the same HTML skeleton. If you view the source, it's pretty simple.

Doing this with JavaScript introduces all sorts of other concerns: accessibility, security, privacy, maintainability, future-proofness, compute necessary to render, render time, etc. jQuery did basically this, right? Selecting markup and content with CSS syntax to munge them, or attach triggers.

I rarely see people write vanilla CSS these days. Most folks abstract it with SCSS or LESS. That removes a lot of the warts. It's still too easy to end up with 5000 lines of CSS that can only be tested by manual inspection :/

<comment><USER10> You can re-style arbitrary (or well-designed) HTML in lots of different and cool ways with CSS. But you can't re-style it to the new particular design that management wants.

And even if I'm wrong, the last decade has proven that your regular above- average developer can't typically do it, and that amounts to the same thing.

</comment></comment></comment><comment><USER11> > Isn't this just inline styles?

Yes it is.

I personally don't like the end result, where by "separating the concerns" you end up hardcoding your style in the HTML markup. For me the utility classes are just exposing the CSS rules to the HTML markup, which I think is actually the opposite of separation of concerns because I when I think of "separate" I think the most of writing code in two different files.

> The amazing thing about this is that before you know it, you can build > entirely new UI components without writing any new CSS.

So, if you want a responsive/mobile version you would have to either serve a different HTML for mobile or also have all the CSS rules for mobile in the inline class names. Before you know, you have a list of 30 cryptic CSS classes written inside the HTML markup for an element.

> How many times have you needed to style some HTML and thought, "this text > needs to be a little darker," then reached for the darken() function to > tweak some base $text-color?

Well, why not just use $text-color--darker? Define your swatches globally beforehand and do not allow the creation of new colors anyhwere else in the code. I guess his solution is similar, but with using another CSS class instead of a variable.

Also, what if at some point you decide to redesign your site and change the margin of all text? So you would have to replace all "mar-6" with "mar-12", but only where the margin is for text. This looks like a complex update invloving a lot of bug-prone search and replace. If it was written as ".text- margin { margin: 6px; }" then it was just a matter of changing one number and you know it would only affect the text-related margin. Sharing style across components is not always a good thing, it makes changing things much harder. I guess with this approach you should never change the initial values, as the entire design might be affected in weird ways.

I am not saying this is completely bad, I am just saying there's no perfect way of doing things and everyone and every project is different.

<comment><USER12> In addition to meeritas point about pseudo classes and media queries, I'd add that the fact that it narrows down the space is an important factor. The classes mean that I need to find the best fit rather than spend hours matching pixels by hand. It's like going from drawing charts on blank paper to grid paper. You stay within certain boundaries. It seems like a detail but I find that in practice (and in fairness, I've only been using Tailwind a bit so far), this makes a significant difference to the way I think and work with UI.

<comment><USER13> This is the equivalent of predefined variables (usable in any preprocessor and now even in plain CSS), nothing specific about Tailwind here. Except for the fact that in the case of Tailwind they are tied to properties, but they are defined globally under the hood, so this doesn't change anything.

</comment></comment></comment><comment><USER14> (Article is from 2017). TailwindCSS is a terrific library.

One area that wasn't covered was the ease of creating truly responsive layouts, inline, by defining different utility classes to the same elements based on screen size. "Responsive" is so much more than just the placement -- quite often, mobile version needs different font sizes, overflow behavior, thinner margins (since there is less screen space), etc. Very easy to do with the utility approach.

<comment><USER15> I find Bulma strikes the right balance in this regard. It feels like bootstrap, only much cleaner, but then it also has these nice responsive classes you can apply. It makes it very, very easy work with.

</comment></comment><comment><USER16> The real issue with css is that there is an enormous amount of code re-use while at the same time almost no code-reuse at all. The author's example highlights this perfectly: he has a "media-card" representing both the "author-bio" and "article-preview" but the "author-bio", in this case, needs to be slightly different. This, to me, is the quintessential css problem.

Almost nothing in css is identical, but almost everything is similar.

This becomes especially true as you move up the complexity spectrum. Primitive things can be identical (fonts, colors, input boxes, etc.), but the real higher-order actual components like pages, forms, sections rarely are. In fact, the little differences, tweaks and custom-tailoring that are manually applied based on context are what separate professional design from robotic enterprise-style Frankenstein design.

I think the answer is that you need both semantic css and utility css. Utility css is used to define the rigid primitives that make up the general design language, while semantic css provides the hooks and separation needed to be able to uniquely compose those primitives into custom higher-order components.

So to answer the author's question regarding how to model "author-bio" and "article-preview", I would personally keep their separate semantic titles, but style them using common utility primitives classes and custom css within the css.

<comment><USER17> In programming, this problem would be solved with something like higher order functions or parametric data types, allowing us to both abstract out the commonalities and maintain incredibly specific, easily modifiable, highly customized functionality. Is there an analog in the CSS world?

<comment><USER18> There doesn't need to be, given CSS-in-JS!

<comment><USER19> It's wild to me that most of the discourse around CSS-in-JS is about personal preference for how separation of concerns should be when its biggest advantage is totally orthogonal to that--it almost completely solves the issues of scope, specificity, and mapping styles to markup that so many different libraries and methodologies have been invented to cope with over the years.

<comment><USER18> upvoted and agreed

</comment></comment></comment></comment></comment><comment><USER20> From my experience, using utility classes like this just means that you'll have a lot of messy overriding to do when your reusable components need to look different in different places.

Personally I think visual consistency is important and you shouldn't make things look different in different places, but it's not always up to me.

<comment><USER21> At least React's "pass an object to the `style` prop" makes it relatively easy to do that overriding.

With utility classes, your code has no way of knowing that "bg-red" should override "bg-blue". (And frequently it won't, if "bg-blue" happens to come later in the CSS file.) So people end up inner-plaforming their own clunky solutions on top.

<comment><USER22> You would be surprised how many people do not know that the order of classes in the source file, not the class="" attribute, matters.

See my (totally unscientific, yet scary) poll of my audience, which heavily leans towards frontend with a focus on React: [https://mobile.twitter.com/mxstbr/status/1038073603311448064...](https://mobile.twitter.com/mxstbr/status/1038073603311448064?lang=en)

Only 43% got it correct!

<comment><USER23> If you do not know basic stuff like that how can you even write CSS at all? Trial and error?

<comment><USER24> From experience with co-workers: Yep, and lots of !important

</comment></comment></comment></comment></comment><comment><USER25> As a designer, the only thing that's important for me in managing CSS is isolation of styles. I apply a reset at the top to make everything as minimal as possible and then apply styling to each element and the naming convention would be such that it applies pretty much only to that element (or only that and its children if I'm being lazy).

If the markup changes, the CSS changes. The nested SCSS should closely mirror the DOM.

I can only imagine utility classes will simply create many problems with naming down the road. I would hate to have to deal with all that.

<comment><USER26> I can definitely see the advantages! But don't you find yourself writing the exact same CSS hundreds or even thousands of times with this approach?

<comment><USER25> Yes and if anything I think I spoke too strongly. I do use classes that encompass a broader pattern, but they definitely don't go as far as "text- right", but perhaps something like, "card" for card based layouts.

</comment></comment></comment><comment><USER27> Author here — a common question I've seen in the comments that I didn't cover in the article is how you do responsive design with this approach.

Here's a link to the responsive design guide in the Tailwind CSS docs that covers it in detail:

[https://tailwindcss.com/docs/responsive- design](https://tailwindcss.com/docs/responsive-design)

The TL;DR is you have breakpoint-specific versions of your utilities, so you can define all of your responsive behaviour directly in your markup.

For example this element would be `block` by default (on mobile) and `flex` when the browser is at or above some defined "medium" breakpoint:

<div class="block md:flex">

Two years after writing that article I can say CSS definitely feels "solved" to me, and every time I have to go back to an old Tailwind project it's very easy to make changes.

If you're building things with React, I'd also encourage you to explore projects like Emotion and Theme UI which allow you to work with the same philosophical approach (styling elements directly instead of through "hooks" and some separate style layer) but with a bunch of neat advantages that aren't possible with a regular class/CSS-based API, like having better control over how style definitions override each other when applied to the same element.

Personally I'm still very happy using Tailwind even in React projects, because the syntax is more terse and it's nice to have a singular styling paradigm that I can use even outside React projects.

<comment><USER28> Thanks for the fantastic library! I've really enjoyed using it and it has sped up dev time phenomenally. However, I am curious: what is it like using tailwind on huge projects? I can imagine with many developers working on a codebase the "extract repeated patterns to their own new class" philosophy can get easily ignored, or difficult to track where some series of classes is being repeated.

</comment></comment><comment><USER29> I think utility classes _first_, and not utility classes _only_, is a reasonable approach. My purist mind would prefer something like semantic classes as a sort of 'public', 'HTML-facing' API, implemented using 'private' utility mixins, keeping the separation of concerns. But in practice, I know I have wasted a lot of time thinking about class hierarcies and separating components, especially when the design is nowhere finalized and I just want a 4px padding.

</comment><comment><USER21> I think the utility-based approach overlooks an important point: semantic class names are useful for a lot of things besides writing your styles.

"Codeless tracking" systems let you put in the CSS selector for a button and find out how many people clicked on it. UI test automation tools let you specify the CSS selector of an element to click on. User stylesheets let people make tweaks to your site if they have accessibility, usability, or aesthetic concerns.

If all your elements have class names like "mt-2 bg-black font-semibold text- white pt-2 pb-3 flex justify-left", you're making it a lot harder for you, your users, and your co-workers to take advantage of this ecosystem. At the very least, you might want to consider _also_ putting semantic classes on your elements.

<comment><USER30> Nothing stops you from adding a semantic class name or ID to a tag for easy reference.

<comment><USER21> Right, but it goes from being something you get for free to being something you have to go out of your way to do. Which can matter, especially on projects where you're designing a site/theme to hand off to someone less technical.

<comment><USER31> I've found that using the same class name for styling and attaching behaviors to be dangerous... refactor the styling and lose the functionality, or break the tests, or disable the analytics.

I'm glad that backbone and jQuery apps are in my rear view mirror at this point.

<comment><USER32> The reason why you're finding this dangerous is because you've coupled your class names too closely with your style. Class names should describe what the content is about, and so if the class names change, that implies that the content itself is different.

</comment></comment></comment></comment></comment><comment><USER33> I never liked to do CSS, but I must admit with the library this guy released (tailwindcss), it's really fun :)

</comment><comment><USER34> >What if we wanted to change how the author bio looked without changing how the article preview looks?

>Before, we could just open up our stylesheet and choose new styles for either of the two components. Now we'd need to edit the HTML! Blasphemy!

The reason you can't is because the markup declares two things to be equivalent, obviously then CSS can't tell them apart. You're not mixing concerns you're lamenting the fact that CSS can't be concerned with markup.

Throwing separation of concerns overboard and making HTML concerned with styling doesn't seem the best resolution.

</comment><comment><USER35> There are lots of positive comments in this thread in support of this approach and I think it's great when anyone challenges the status quo.

It is more common these days than it was for websites to support multiple styles/layouts. Whether that's because they're responsive or because they allow you to enable dark mode or because they support rtl layouts. Class names such as text-dark-soft or align-right will be misleading if text-dark-soft ends up closer to white and align-right is left aligned as a website is evolved to support these features.

Not a criticism of this approach; this is easily fixed by using names such as text-emphasized-soft or align-start (for example), just pointing out the examples in this article could be lead to problems

CSS variables can also be used to encourage picking colors or padding/margin from a curated list. The approach in this article is not required to solve that problem

</comment><comment><USER18> MODS: OP is from August, 2017; maybe add "(2017)" to the title given how long 27 months is in webdev?

</comment><comment><USER36> Maintenance of these utility class CSS codebases is such a pain. I've had the pleasure of dealing with it. What if you want to tweak one of your utility classes ever so slightly? If your codebase is big enough, you've just created enormous amounts of potential regressions.

<comment><USER37> Give me an example of that.

Would you mantain .display--block? how? .color--red?

<comment><USER36> It would be some domain-specific component. Like .product-card. I don't see the examples you've given. Those are so literal, you might as well use inline styles at that point.

<comment><USER37> That's the problem functional CSS solves: class naming doesn't relay on developer intervention, it's just a translation of the utility.

Product-card is not an utility, that's why it's a problem to maintain such classes.

</comment></comment></comment></comment><comment><USER38> Adam is an awesome follow on Twitter. I still haven't come around to his way of thinking on utility classes. It feels messy compared to a component based approach. But, I totally respect his work and can see myself adopting something like this in the future.

</comment><comment><USER39> I've been writing sites like this for years.

It can look sloppy, but I find that it's important to provide as many "hooks" as possible to elements; especially dynamically-generated elements.

This is because I've written tools that were meant to be integrated into sites, as opposed to the end site, itself.

It was important that the user of the tool be able to exert as much control as possible over the rendering.

It does look messy as hell, though. Inspect Element is very helpful. Since a lot of the dynamic code is optimized anyway, or rendered by AJAX, display page source is kinda worthless.

It's all about keeping the specificity as weak as possible, while allowing the CSS to focus on individual elements, or collections of elements.

<comment><USER39> Also, for anyone that cares, I wrote up a series on CSS-based Web design about ten years ago: [https://littlegreenviper.com/series/cssdesign/](https://littlegreenviper.com/series/cssdesign/)

It's dated, but still absolutely relevant.

Here's the start of the specificity section, which goes on for some time: [https://littlegreenviper.com/miscellany/stylist/introduction...](https://littlegreenviper.com/miscellany/stylist/introduction- to-specificity/)

</comment></comment><comment><USER40> You can have many classes. So in your markup you can have an item that is both class article and class bio. Then on another page that is the same but different the class can be article preview. Then in the CSS you make rules for .article and where bio and preview differs you use .article.bio or .article.preview respectively.

In CSS specific rules overrides general rules. So .article.bio would inherit all .article rules and also override.

I like to start out my style sheet (CSS) by only using the semantic HTML elements like h1, button, etc. Then when the design advances and I go down to the small details - I add more and more specific rules.

</comment><comment><USER41> This very long article leads to the following point:

\---

> Utilities force you to choose:

Is this text-sm or text-xs?

Should I use py-3 or py-4?

Do I want text-dark-soft or text-dark-faint?

You can't just pick any value want; you have to choose from a curated list.

Instead of 380 text colors, you end up with 10 or 12.

</comment><comment><USER42> This is a particular dilemma I've tried a lot of different approaches for. One thing the article didn't touch on is what happens on responsive, where often margins can change multiple times between desktop and mobile.

For a while now I've been effectively writing semantic css (nested or more recently bem) composed out of non semantic sass helper functions. The benefits of this are being able to think about namespacing in very simple terms. It can make for fairly large css output files though, something BEM helps with a bit.

</comment><comment><USER43> This article is interesting, but not for anything having to do with CSS:

1\. Start with a given approach, but say you feel something "off" because it doesn't quite fit "best practice xyz".

2\. Use another approach, which _also_ doesn't fit "best practice xyz".

3\. Argue that the best practice shouldn't be a best practice.

This of course, should mean that the very first approach is just as alright as the second, yet here it is used to defend _only_ the second (sure, there's a token acknowledgement of the first approach being valid too under the new assumption, but everything afterwards is a long "but not really, second one is the true better one").

Back to the topic at hand, the article depicts a circle: let's move away from inline css by... moving it one attribute over, to "class". The token attempt at contradicting this is unsuccessful one because, as much as there's no limit in the inline css you can do, there's no limit to the amount of classes you can add. So it all ends up feeling a bit self-defeating.

Ultimately, this article, IMO, is a good example of this: [https://christine.website/blog/experimental- rilkef-2018-11-3...](https://christine.website/blog/experimental- rilkef-2018-11-30).

Then again, I'm a developer first and foremost, maybe I'd like this better were I a designer.

</comment><comment><USER44> I love the analysis in this post. I think utility functions along with a set of design tokens (Styled System [1] / ThemeUI [2]) is a better mechanism and achieves the same end goal as utility-first CSS, at least in the React ecosystem.

1\. [https://styled-system.com/](https://styled-system.com/) 2\. [https://theme-ui.com/](https://theme-ui.com/)

<comment><USER45> Yeah, it's technically better than Tailwind CSS, but unfortunately JS/React only.

</comment></comment><comment><USER46> I wanted to point out some of the downfalls of utility classes, but then realized that my main objections are with the HTML-CSS model itself. Adam was, as we all are, trying to make the best of this weird web dev situation. It is the discussion itself that is the most valuable imo.

Architecture is not a striving toward perfection, it's a collaborative process of finding heuristics that give good results based on real-world constraints.

Things to consider:

Utility classes do not do well when there are multiple states involved (as a simple case, consider :hover). Libraries that use the CSS utility classes do not follow the "Open-closed principle" or the "Dependency Inversion Principle" – depending on the mental model you use.

The term "functional CSS" is a misnomer, since the composition of styles happens at the HTML layer. Calling it "mashup CSS" would be far more accurate.

One huge problem in writing any software is figuring out how to make good decisions about where and how to compose smaller building blocks into bigger ones. Category Theory helps with many of these questions, but is far from sufficient to answer all of our questions. So it's quite valuable to discuss and try new things.

</comment><comment><USER47> I've been using utility classes for a few years now. Some thoughts I've come up with:

For content heavy sites like ecommerce/marketing/blogs, I use pretty much utility classes exclusively. There usually isn't much reuse of UI components on these types of sites so maintenance is much simpler compared to semantic classes. With semantic classes you'll have a lot of one off styles.

I actually really enjoy writing sites like these since I can code a site start to finish without touching any CSS files. Using utility classes I probably finish 25%-50% faster than if I were to use semantic classes.

On more web app type things like admin panels, I use a mix of mostly semantic classes and a few utility classes. I only use utilities to make sure there aren't a million different padding/margin/font size values.

In the earlier days of React I tried using all utility classes and it just felt like there was too much going on in the JSX. If you use utility classes, you know the class attribute can get pretty long - sometimes needing to be broken into 2 lines. The CSS tooling with Webpack has come a long way and solves a lot of the problems that all the utility class frameworks were trying to solve around 2015.

</comment><comment><USER48> I really like how the author progressed from semantic to utility with examples. This approach made it really easy to understand the... uh... utility of utility classes.

The answer to anyone asking "how is this not inline styles", is in the article. With utility CSS, you don't use 100% of everything that CSS can do, and just pick the exact snippets you need for your theme.

</comment><comment><USER49> What's always missing from these perennial CSS deep dives is that HTML already gives us a paradigm worth extending: generic constructs, used in domain specific contexts. Generic constructs are those that are devoid of domain specifics and can be used by HTML documents from other domains, e.g. links, paragraphs, buttons, tabs, and modals.

A link can refer to a user profile page or a news article. Both use the generic anchor "component", which comes from the wider universe of components applicable to most/all HTML docs. HTML: `<A class="user">`, CSS selector: `A.user`.

To extend this, a media card could represent a video or a book or a sidebar item. Both use the media card component's HTML structure but can be tweaked visually with CSS. The root element of the video media card would be `<DIV class="MediaCard video">` and would be identified with the selector `DIV.MediaCard.video`.

(PascalCase is arbitrary but I like that it harks to class naming conventions from OOP languages. You'd need some other naming conventions as well. I like `_title` for internal element class names, like private class members from OOP languages. Internal selectors would be built using the performant child combinator. Some of these patterns are more verbose than current alternatives, but it's also the minimum necessary to get crystal clarity around inherited and cascaded values. Preprocessor nesting makes this less painful. And `-highlight` for variants, because they resemble CLI switches. What about non- generic components? Those aren't "components" as defined here - they are simply higher-level HTML fragments, typically organized in source as an HTML template.)

This gives you two dimensions along which to flexibly organize things - <USER2> generic forms and the domain-specific applications, and should keep you from slipping down the slope to utility-dominant CSS.

</comment><comment><USER50> The decision to make CSS libraries that are reusable across all parts of your application is spot on. Also it helps with theming, eg dark mode. To avoid listing tons of classes on each element, you can use something like less:

        .my-class {
          .utility-class-1;
          .utility-class-2;
        }

Reusable constants also help a lot.

<comment><USER42> On the dark mode thing, another way to do this is using css variables like --color-foreground for example. The whole site can have dynamic colour themes with minimal effort after that.

</comment></comment><comment><USER51> Question: I used CSS utility classes for building components in VueJS. The problem I ran into was that I wanted to apply classes only when certain conditions are met, i.e. style the component slightly differently based on its state. This caused me to check the condition repeatedly – once per class I want to apply. Is there a better way, e.g. applying all classes together after checking once?

TypeScript/JavaScript:

        export default Vue.extend({
            data() {
                return {
                    isActive: false,
                };
            },
            computed: {
                componentClasses() {
                    return ["margin-4", "padding-3", {
                        "color-red": this.isActive,
                        "font-size-30": this.isActive,
                        "font-weight-700": this.isActive,
                    }];
                }
            }
        });

<comment><USER52> the docs:

[https://vuejs.org/v2/guide/class-and-style.html#Binding- HTML...](https://vuejs.org/v2/guide/class-and-style.html#Binding-HTML-Classes)

[https://vuejs.org/v2/guide/class-and-style.html#Array- Syntax](https://vuejs.org/v2/guide/class-and-style.html#Array-Syntax)

In your template:

a) <div :class={active: isActive} />

b) <div :class="{isActive? 'active' : 'inactive' }"/>

<comment><USER53> B) is not valid. It needs to be wrapped in an Array, not an Object.

</comment></comment></comment><comment><USER54> I feel like one thing that isn't addressed is the way designs are often made. Using utility classes requires that your designer is also aware of this and uses it. My experience is that most of the time this is not the case. You will end up having to make a lot of utility classes for single cases.

</comment><comment><USER18> In terms of applying styles to pages / component hierarchies, I find it useful to think in terms of "global / baseline", "layout", and "utility classes". I wish layout were always viewed as a first-class concern, entirely separate from branding, colors, etc.

I think "Every-Layout" ([https://every-layout.dev](https://every-layout.dev)) makes an extremely compelling case for this approach. I'd love to see an example of a design system leveraging these beautiful, coherent, logically sound typography-based layouts, incorporated w/ modern component architecture, ready to be customized and themed. IMHO that'd be as transformative now as twitter bootstrap was when it first arrived.

</comment><comment><USER55> Separating HTML from CSS has no basis, they are both concerned with the visual organisation of information. I feel that the real problem is not with CSS, but with how HTML forces you to jointly specify the semantic structure of data with its layout.

</comment><comment><USER37> Anyone interested in a framework to produce functional CSS in SCSS/Sass, this is my project [https://github.com/meerita/utilcss](https://github.com/meerita/utilcss)

</comment><comment><USER3> I use a method called Context and Components. The idea being to build components, and to modify those components of they need to change base on context.

From my experience, reusable CSS is somewhat of a red herring. Maintainable and easily locates CSS is where you get productivity gains. If you don't know what you habe because there are hundreds of utility classes then what good is it. Also, if you are using utility classes why not just inline CSS? "red- border" is jusr as

</comment><comment><USER56> CSS felt "solved" for me when the React team introduced inline styles. I've been using them ever since and it has made styling a breeze. I know people balk at inline styles, but I still haven't heard a convincing argument as to why they are a bad thing.

<comment><USER57> Lots of rule duplication and no pseudo-selector support with inline styles. If you like using inline styles, I think you'd like CSS-in-JS, because it has a similar feel when writing components with the benefit of deduped atomic classes as critical CSS + pseudo-selector support.

</comment></comment><comment><USER58> The mistake in my opinion is trying to write HTML and CSS that is a Swiss army knife of everything you'll need. Understand the problem at hand in the project you are working on first and write HTML and CSS to tackle that problem.

</comment><comment><USER59> What I figured out over the years, is that CSS is not an afterthought. You need to engineer a solution for your design as you are building the html.

<comment><USER60> If you treat your CSS as a value-add, I've found you can often treat it that way. I've designed sites that work fine in text-based browsers, and then I stick CSS on it to make it look pretty on your phone.

</comment></comment><comment><USER61> Ended up looking a lot like Bootstrap to me.

</comment><comment><USER62> Too much work.

A-b_c is so multiplicative

</comment><comment><USER63> In my opinion the problem is that CSS apply styles _and_ positioning to markup

Components have been a solved problem in desktop apps for decades

You have layout and styles applied to components positioned in the layout

What's really problematic is having a presentation layer that's split in layout and styles in the same context (CSS) while content and structure are both exposed in HTML

If we had layout in HTML and styling in CSS it would be easier to reason about it

HTML was born to give the document structure, layout is in the same league if you ask me, but then styles became the only way to lay out content, HTML lost its purpose of being the way to structure content in a meaningful way so you have the same HTML behaving diffentely with different layouts just because CSS can work on both of them

If footer meant "stuck at the foot of content no matter what the content is" we could have saved a lot of engineering hacks around making it reusable

</comment><comment><USER64> This just seems primitive to me, use a UI framework and make ur life easier...

</comment><comment><USER65> For me, CSS has been a Solved Problem™ for 5 years now.

If a website is small then I write plain HTML/CSS/JS in the old school way and all of these abstractions/systems are YAGNI.

If a website is large enough for these abstractions to matter then I'm using React with inline CSS. I get reusability and composition without a noticeable performance tradeoff. You can still build your components to decouple style from content where needed. Up to you.

Years later, no issues.

<comment><USER11> How do you re-use this inline CSS?

<comment><USER21> Not the parent, but the approach I've seen in React is to treat inline CSS as objects like "{ fontWeight: "bold", color: "#000" }". So to re-use it, you can either put it in a constant or make a component that applies the styles to an element (and maybe takes props to override them).

<comment><USER11> I was asking because doing this just looks like normal CSS, where you define a class and use it in multiple places, only that it's in JS instead, so you still have all the "problems" mentioned in the article.

<comment><USER24> The major downside of reused inline CSS is when you have to do minor tweaks (where active manipulation in the browser devtools is by far easier to find the right values) and those inline styles are on the page multiple times. Editing one class's rules is significantly easier than all the repeated inline styles.

<comment><USER65> With the inline CSS approach, components are your reusable entities not CSS classes.</comment></comment></comment></comment></comment></comment>


Backblaze 7.0 – Version History and Beyond - <AUTHOR> https://www.backblaze.com/blog/backblaze-7-0-version-history-and-beyond/ <comment><USER2> In case someone at Backblaze is reading this : I had a less than ideal experience in the past couple of days, trying to report through normal support channels a potentially critical bug breaking the "inherit backup" feature in the Mac client.

Here goes : a few days ago the Backblaze Mac client started prompting me to upgrade urgently to the latest version (18.104.22.1680). I went ahead and did that but got "Installation could not complete, please contact support" each time. Support advised me to wipe /Library/Backblaze* , reinstall, then inherit the existing backup.

Well, we never managed to get the inherit process to complete : it failed with "ERR_error_unknown" every time. And I started freaking out.

That's where things get interesting : I became frustrated with the canned responses from support and decided to delve into the client logs myself. I quickly found a potential smoking gun (in bzbmenu.log) : a spelling mismatch in an XML attribute name between the server response (support_inherit="true") and what the client was expecting ("ERROR could not read attribute named supports_inherit"). Notice the extra "s" ? Pretty obvious typo and one that could definitely explain the failure (client can't confirm that the selected backup is eligible for inheritance, bails out)

I was rather happy with my findings and shared them in plenty of details with support (including log excerpts), but instead of a "thank you and here's some free months of service !" response, I got "meh, this log file is irrelevant", and worse: no promise to escalate the issue (until I insisted a second time). They suggested updating to the 188.8.131.522 beta, which turned out to have the exact same bug.

Now, I'm left wondering if should try upgrading to 7.0 and inheriting my 6.1 backup from there. But the point of this message is to share my disappointment with this support experience. I went out of my way as a customer and spent a couple of hours researching and finding something potentially useful to the company, but had no appropriate way to report it. I even tried security contacts, but was (rightfully) told it wasn't a security issue. No word on whether they were going to pass it on to the relevant team.

EDIT: I've just confirmed that the same issue is present in 188.8.131.526. Still can't inherit my existing backup.

<comment><USER3> Yev here -> I'm reading! If you're able, please send me the ticket number so that I can review that exchange and escalate it. I'm sorry that support didn't appear grateful for your debugging efforts, but I'll make sure that it gets in front of the developers who can examine the issue.

I would update to v7.0 - it does have a lot of minor fixes in there as well (not sure if inherit is addressed, but worth trying).

<comment><USER2> Wow thanks Yev ! It's #499226

No hard feelings at all against the support guy, who probably has to deal with dubious customer claims all day. But it was pretty frustrating when he told me the log file I looked at couldn't possibly have anything relevant in it, when I had in fact just showed him plenty of relevant things from it :)

<comment><USER2> Well, not trying to turn this into a support forum any further, but I've just upgraded to 7.0 and right now SMS 2FA seems broken ("The verification code is invalid" every time)

<comment><USER3> Yev here -> I'll do support wherever I see my bat-signal :D Do you have an alternate method set? If you reach out to support -> [https://help.backblaze.com/hc/en- us/requests/new](https://help.backblaze.com/hc/en-us/requests/new) (they have live chat right now) - they can try an alternate method if our primary provider isn't reaching your device!

<comment><USER4> It's completely broken here as well, which was really frustrating. I already wasted 117 days of a yearly subscription on one machine because it ran Catalina Beta (which was my fault, I needed a test machine, and I ate the time lost without complaint), but not being able to inherit that back up really sucked afterwards.

<comment><USER3> Yev here -> Have you reached out to support about the issue? They are working with our devs to track all of the issues and could use the additional data points -> [https://help.backblaze.com/hc/en- us/requests/new](https://help.backblaze.com/hc/en-us/requests/new). It's working for most users, so we're trying to whittle down the issue.

<comment><USER4> It's too late now, I already wiped the old backup and reassigned the license. I didn't feel like wanting to waste the time much further after past experiences with support and what I read here.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Are you (BackBlaze) still happily deleting user's backup files if user's computer does not contact BackBlaze servers within some arbitrary time?

Yes/No?

Source: [https://help.backblaze.com/hc/en- us/articles/217664898-What-...](https://help.backblaze.com/hc/en- us/articles/217664898-What-happens-to-my-backups-when-I-m-away-or-on- vacation-)

This is malice.

If you are still doing this to your users - your service is a non-starter. Backup service that deletes user's valuable files under some TOS excuse should not exist.

<comment><USER6> Backblaze is a backup service, not a file storage service.

If the computer you are backing up isn't online for 6 months, it clearly isn't that important. If it is, you can use B2 to store files indefinitely.

<comment><USER7> > If the computer you are backing up isn't online for 6 months, it clearly > isn't that important.

Internet connectivity in some parts is particularly terrible.

My grandmother's ADSL 12/1Mbit connection was never particularly reliable and would go down any time it rained for days at a time. Every 6-12 months it would go down hard and not come back requiring a visit - the techs would fiddle around, find a different working copper pair and get it going again.

Finally, about two years ago it died completely, and the Telco threw up their hands and said they couldn't fix it, there just wern't any working pairs. There will be, at some point, a FTTC rollout, but in the mean time we're getting her limping along with an overly expensive and even less reliable 4G connection. The data limits are absurdly low, so I can't afford to let Backblaze actually run backups.

But the data that was backed up prior to the DSL outage we want to keep - I'm paying the license for it, they should keep it.

<comment><USER8> That setup is simply not suitable for using Backblaze, or actually any kind of off-site backup.

What would be an interesting solution, is to run a simple gigabit ethernet line to a neighbor or even the backyard shed. And set up a backup endpoint there. It's not totally off-site but sure beats the alternative.

<comment><USER9> It's not suited for it right now, but it very much disproves "If it's offline for six months, it clearly isn't that important."

</comment></comment></comment></comment></comment><comment><USER10> I've only ever had one problem with Backblaze, in my ... 7 or 8? ... years as a customer.

The problem: The UI for excluding directories is _horrific_. It uses the Windows "Browse for Folder" *SHBrowseForFolder) dialog, which requires you click down through each and every level of your directory structure to get to the directory you want to exclude. You can't cut and paste, it doesn't start from the directory you added your last exclusion in, it's just lots and lots and lots and lots of clicking.

This doesn't seem like it would be hard to fix, so I'm guessing they don't consider it broken?

If the Backblaze folks are still reading: Could you please, pretty please, with sugar on top, for the love of god, fix your fucking exclusions interface? Please?

<comment><USER3> Yev here -> if you don't want to use the UI (meant for non-tech savvy folks) we do have advanced exclusions via XML - take a look -> [https://help.backblaze.com/hc/en- us/articles/220973007-Advan...](https://help.backblaze.com/hc/en- us/articles/220973007-Advanced-Topic-Setting-Custom-Exclusions-via-XML).

<comment><USER10> That's the thing -- I _do_ want to use the UI and I don't want to have to hand-edit XML. I just want the UI to not use the single worst dialog box in all of windows.

I am baffled at why Backblaze clings so tightly to the existing dialog box.

</comment></comment></comment><comment><USER11> i've been a customer of backblaze for a about a decade now. everyone has their opinion, but for me, it's always just hummed along in the background, doing it's thing. i've had to restore almost a terabyte of data (on more than one occasion, derp) -- and had no issues.

it's up there (again, for me) as one of the annual software subscriptions that's worth every penny, if not more.

<comment><USER12> I'm curious how you did the restore and roughly how it went? I've done a few restores years ago. I don't know if this reflects the current process, but my experience was a bit rough. However, I'm still a long term customer with little interest in going elsewhere.

In late 2016 my laptop's drive died suddenly. I tried to restore everything via a shipped drive. I'm not sure if it was because of copy on their website (at the time) pointing out that they overnight USB drives or me just expecting that's the fastest way to get my data, but I was disappointed at the turnaround. Because it was a relatively large amount of data (a few hundred gigs?) there was a "staging" process that took a day or two. It got interrupted and had to start again (a server reboot on their side?). After receiving the drive everything went smoothly; I believe the data had been encrypted in transit, but wasn't onerous to restore from. I even think I was outside of their 30-day return and it wasn't an issue (the problem wasn't my hard drive, but a cable...with no hot spares and a special cable it took longer to resolve). At work I had a similarly annoying experience with Amazon Snowball where physically locating it and "testing" it took a few days longer than expected when expecting tight turnaround...maybe I need to adjust my expectations for physical logistics.

Many years previous I noticed my music files were showing up as 0-size--my hard drive was failing. Thankfully I could pull my collection from 30 days previous and I chose a download option. It was a bit annoying that they had created a series of zip files (which makes sense), but I believe I was restricted to the web interface for downloading them which made managing it difficult.

<comment><USER13> For me the restore experience was painful.

I attempted to restore about 1TB of data (on macOS). Since I have 500mbit internet I assumed I'd be able to download it through the app, but that didn't prove easy. Even when split into smaller zip archives, the download would go terribly slow. Often, the archives would be corrupted and I'd have to re- download them.

In the end I had to order a drive to Europe (and pay the tariffs), which is a pain in the ass. (But they did return the deposit even though I missed the 30 day window.)

Edit:

Oh yea, and when you loose your data you have only 30 days to get it back before Backblaze deletes it as well! That's what happened to me right before a multi-week trip, so I was pretty unhappy that I wasn't able to download my backup in the 5-or-so days I had at my disposal, thus having to order the physical drive.

<comment><USER14> > when you loose your data you have only 30 days to get it back before > Backblaze deletes it as well!

Uhhh... this one could be a significant issue for me right now. I've got a laptop that's been offline for about 2 months now due to a motherboard failure due to liquid damage. I haven't bothered dumping the drive yet because I figured even if it's got issues Backblaze has a copy.

You're telling me that if I login to my account right now, the data is gone? If so, they really need to make that one more obvious.

EDIT: Just checked Backblaze, still looks like the data is there after 70+ days. Has this policy changed at some point?

<comment><USER15> Disclaimer: I work at Backblaze.

> Has this policy changed at some point?

It is more complicated than just "after 30 days" (and always has been). If your laptop is entirely offline (or you simply uninstall the client from your laptop), then the policy is ACTUALLY that we keep your backup for 6 months as long as you keep paying your bill. But to be honest, it's more like a year or two. The 6 month policy is we guarantee the backup will be preserved, not that we will immediately go out and delete it at exactly 6 months and 1 day.

This is a completely different situation than files you delete but the backup continues. For cost reasons, Backblaze purges the files that you deleted from your local drive after 30 days. HOWEVER, with this new 7.0 release you can pay a little more and increase that retention time to one year, or forever. This was a highly requested feature for the situation you ran into.

Or, if you have a hard drive that you disconnect and aren't willing to reconnect for more than 30 days. Since your backup is continuing, Backblaze assumes the drive will never come back, so the files are then deleted to save money in the datacenter. Of course, this changes with the 1 year retention policy, you can unplug the drive for up to 1 year and still dial back time and restore all your files.

<comment><USER16> > HOWEVER, with this new 7.0 release you can pay a little more and increase > that retention time to one year, or forever. This was a highly requested > feature for the situation you ran into.

I'm glad to hear that Backblaze has finally made such an option available. However:

> For cost reasons, Backblaze purges the files that you deleted from your > local drive after 30 days.

As someone who once almost lost his PGP key and had to recover it from old physical backup media, I'd like to point out that that is not a "backup" service. It's sort of like a lazily expiring mirror, but it's definitely not a backup service.

Do you look at all of your files every 30 days? How long would it take you to notice that a random file had disappeared from the filesystem 7 layers deep? Have you ever needed to restore a years-old file?

(You need not explain why you do it; I understand about users who could use it as a cloud storage service by deleting files after they're backed up. The point remains that it's not a _backup_.)

<comment><USER12> What's your criteria for backup? I completely agree that something like RAID is not backup, but 30-60 days seems comparable to other backup services and covers most scenarios. The old-school manual process of swapping a USB drive at work every week/month has the similar retention.

The only consumer-facing system I've used with multi-year retention is Time Machine. Every few years it has trouble "verifying" the backup and I have to start over (it also deletes old backups when you run out of space). Right now my backup only goes to August.

<comment><USER17> Backup means that if it takes me 6 months to realise that the 2014 finances folder had been accidentally deleted, I can still recover it.

I'd love to see BackBlaze offer the option to select "mission critical" folders that have super-long-life (Time Machine-like) version retention. Give everyone a few gigabytes of this for free, charge a premium to increase that space.

<comment><USER9> Though that sounds tricky to set up all the UI for. For now you can set up a separate backup of that stuff. Set B2 as the backend and you get 10GB free.

<comment><USER17> Maybe—and the UI could be little more than a script that does exactly what you described.

The point of making it a UI is, first and foremost, to get people thinking about this question. And it gives people the option to acheive what you just described without stumbling upon a post like yours on Hacker News.

<comment><USER9> A post like mine? But it's your post that has the idea...? The only thing I said about how to make it possible is "separate backup", which anyone can think of in two seconds and is only a hint of a tenth of an explanation. I don't understand.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Cool changes! Any plans to ever add Linux support? That's a dealbreaker for me. I need to backup both Linux and Windows machines. I wanted to use B2, but restic seems not ideal on Windows.

<comment><USER3> Yev here -> No plans on the Computer Backup side. We haven't been able to come up with a way to do it affordably and in a way that makes sense for us - so we recommend folks use B2 Cloud Storage and any of the integrations that work for both. Cloudberry and Comet backup work pretty well. You can see more on: [https://www.backblaze.com/b2/integrations.html?platform=linu...](https://www.backblaze.com/b2/integrations.html?platform=linux&use- case=backup) (I set it to use Linux + Backup as the parameters).

<comment><USER19> B2 isn't really a solution for people that are looking for a robust computer backup service like Backblaze currently offers for Mac and Windows. I went down that road and ended up very frustrated.

I ended up buying a Synology NAS (which _does_ offer the same computer backup features + revisioning and all that), and then syncing the backup out to B2. It's not an ideal solution by any means, and I would get rid of my NAS in a heartbeat if there were a real solution for Linux desktops.

It really sucks to have had to go through all of that setup (+ have another machine to maintain) when I just wanted to get things done and know my data was safe.

Would you consider working with the community to find a better solution? Maybe offer a closed source library (a la libspotify, but for Backblaze) for the storage bits + get the community pointed in the right direction for an open source frontend for Linux or something?

<comment><USER20> I imagine the problem isn't closed vs open source, but the fact that on Linux it would be trivial to mount a massive NAS (think dozens of TBs) in a way that's completely invisible to the Backblaze client and pay $6/month for unlimited backups. There were people on /r/datahoarder who stored _petabytes_ on Amazon's "unlimited" backup before the whole product got canceled.

<comment><USER21> You can do that on Windows too can't you?

<comment><USER20> I'm not familiar enough with Windows to answer that, but I imagine HTPCs are much more likely to use Linux and would make a $6/month backup a very attractive target.

<comment><USER15> Disclaimer: I work at Backblaze.

> Can you abuse Backblaze on Windows or Macintosh?

Backblaze lives on the "averages", and so far the averages for Windows and Macintosh have worked out for us. We don't have any deep pockets (no VC funding) so we have to stay profitable or die. If you are curious what the distribution of customer sizes is, here is a histogram (you will need to zoom in, then use the scrollbar): [https://i.imgur.com/iVEuwUT.jpg](https://i.imgur.com/iVEuwUT.jpg)

Backblaze does not allow running the "Personal Backup Client" on Windows "Server" OS flavors to help the averages. Macintosh are really super successful in the laptop category, but very very few people or businesses run them as servers so again, the averages work out for us (so far).

However, in all of our market research, the Linux users averages would quickly drive us out of business. By definition, Linux is pretty much dedicated to almost exclusively servers, and exclusively dedicated to SUPER technical people who understand exactly how much data they have. We built "Backblaze B2" expressly for these technical customers running Linux. If you know how much data you have, and you have less than average, you will literally save money with Backblaze B2.

<comment><USER22> I appreciate the directness and transparency of your reply and backblaze in general.

I also appreciate your focus on providing the value you know you can to your core audience. Compromising that attention which, as you noted, would possibly jeopardize your ability to exist at all. A ton of companies get this completely backwards.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> Any plans to restore an encrypted backup without having to send the private key to Backblaze servers?

<comment><USER9> Looks like yes, but it's not a particularly high priority, based on [https://news.ycombinator.com/item?id=21205948](https://news.ycombinator.com/item?id=21205948)

</comment></comment><comment><USER24> I really miss Backblaze. I was a customer for years and years and actually was fortunate (I guess?) enough to have to use them to recover around a terabyte once but when I switched to using a Chromebox as my daily driver (then a Chromebox 2) I found I was turning my Windows machine on once a month just to keep kosher with the Backblaze servers.

Such a great service and I still always look forward to the emails, stuff like the drive failure rates is always a neat read!

<comment><USER25> > I found I was turning my Windows machine on once a month just to keep kosher > with the Backblaze servers

I've been burnt badly by this, I wish there was a better way. I was in the habit of doing this and when I fired the drive up for some reason it failed to be backed up and the backup was deleted at their end. 1TB had to be re- uploaded on a 4Mbps connection. I know I shouldn't have done the backup on the last day (no data had changed) but wow was that irritating.

<comment><USER24> Fortunately for me I realized none of the 5~ terabytes on that machine mattered whatsoever as I never actually used any of it.

I would archive podcasts I liked, download YT videos I found worthy of it, I had 100gb or so of 9/11 news coverage from the day of the attacks and the next few days, insane amounts of exes for pretty much every revision of every scrap of software I used in case I ever wanted to go back to an old version, insane amounts of images from where I'd rip entire tumblr accounts based around different fandoms/topics, I had half a century of Lodge meeting minutes for one of my Lodges scanned as high-resolution OCRd pdfs, entire websites I'd wget for offline (why?!) viewing etc. It's all presumably still there but I haven't turned that box on in about a year now.

Man, switching to a Chromebox was so freeing.

</comment></comment></comment><comment><USER26> Do they still have a very slow upload performance with their backup service? That's been the main complaint I've been reading over the years. (I'd probably be happy with something in the range of 50-100 Mbit/s.) (My home connection is 250/100.)

<comment><USER3> Yev here -> try it now. We've spent the last few updates honing in the way we handle uploads and have introduce threading to make the process more efficient. We'll always be bottle-necked by the available bandwidth to your machine and latency, but it's worth trying again if you haven't for a while!

<comment><USER26> Sure, but you surely you have stats? And why is latency a factor - surely you can work around that by improving your network protocol (think less TCP, more QUIC or something similar, etc)?

Anyway, okay, I'll test your trial again. :)

<comment><USER3> This speedtest is somewhat accurate and is pointed to our data center so should give you a decent idea of speed -> [https://www.backblaze.com/speedtest/](https://www.backblaze.com/speedtest/). The reason latency is a factor is that it affects how quickly data leaves your computer and gets to our data center, so if you're far away, it can play a factor!

<comment><USER27> Unless I missed some setting it seems like the speedtest is only for the US data center(s). Is there any way to test the speed to the EU data center?

<comment><USER15> Disclaimer: I work at Backblaze.

> Is there any way to test the speed to the EU data center?

Create a free Backblaze account in the EU datacenter region. Then upload/download some data! The first 10 GBytes of B2 is 100% free, you don't even need to give us a credit card so you can try it all utterly risk free with no way we could mess with you.

If you run the Backblaze Personal Backup, make sure you manually configure it to use 30 threads, then let it rip and watch your bandwidth meter to see what it can use. The first 14 days are completely free, again no Credit Card required! Personally I get about 100 Mbits/sec from my home in California to the European datacenter (capped by my ISP), but if you are in Europe you should be able to hit 500 Mbits/sec using the Personal Backup Client with 30 threads if you are close enough to Amsterdam (where the datacenter is). Oh, one hint -> don't judge Backblaze Personal Backup until you have been backing up for at least 12 hours. Backblaze backs up small files first, and the latency to push 1 byte files murders performance. But after we get through all your small files, it should rip.

In the end, everybody has enough bandwidth to reach everywhere in the world now, and you really shouldn't pick a service based on total throughput. I think you should pick it based on cost, comfort with the security model and how sensitive your data is, ease of use, etc. Unless you have a Petabyte or more of data, you can backup hundreds of TBytes to anywhere in the world nowadays. Easily. No problem.

</comment></comment></comment></comment></comment></comment><comment><USER28> Very surprised it took this long to implement. I've had a good experience with B2B + Duplicati, but the main reason I went with that over the simpler Backblaze Cloud was the retention policy. 30 days to recover files was just too short of a time span to be a guarantee that my files were safe.

<comment><USER3> Yev here -> Glad you're enjoying the Duplicati integration with B2! It did take us a while, but we wanted to make sure that we did it the right way and in a sustainable fashion. It's been an ongoing project for the past 10 months or so - and came after a lot of customer demand following CrashPlan leaving the consumer market. We're hoping people dig it, apologies it took so long!

</comment></comment><comment><USER29> Does backblaze co. have access to the contents of your backups or is it client side encrypted?

<comment><USER3> Yev here -> the backup service is client-side encrypted before transmission.

</comment></comment><comment><USER30> Yev, can you clarify whether this new release supports NAS? I see that it allows you to "Back up all your attached external drives", but my drives happen to be connected via Ethernet.

<comment><USER31> Probably not. They've said repeatedly that unlimited storage for $5 wouldn't be a sustainable business model if they supported NAS. For that there are third party solutions that support backing up to B2.

<comment><USER30> Thank you, I know the history and what they've said in the past, and also know about their B2 product. I'm hoping for a real answer from Yev, but if not I've been reasonably happy with CrashPlan (which is a NAS-friendly solution).

<comment><USER31> TIL:

Crashplan doesn't support backing up NAS on Windows but does for Windows and Linux. Interesting....

That being said, I think if I had a NAS, I would want a solution that runs directly on the NAS instead of depending on a host computer.

<comment><USER30> > _…I think if I had a NAS, I would want a solution that runs directly on the > NAS instead of depending on a host computer._

Yeah, you could totally do that using a VM on the NAS. The only downside is that it'd be charged as an additional device, assuming you still wanted to back up your main workstation.

</comment></comment></comment></comment></comment><comment><USER32> Hm, if I turn on 1-year-history or history-forever and includes my node_modules folders in the backup will I fill their whole storage cluster?

<comment><USER3> No, but don't do that. :P</comment></comment>


Avoid a Common Software Bug by Using Perl 6 - <AUTHOR> http://blogs.perl.org/users/ovid/2015/02/avoid-a-common-software-bug-by-using-perl-6.html

<comment><USER2> A comment on Ovid's blog post says:

> Perl 6 does some compile time type checking but it only works in some very > simple cases.

I was thinking that all P6 code had static types that were checked at compile- time and some code, not much, also had dynamic types that were checked at run- time.

In the form of a question/answer series, here's how I thought things worked:

> When are types checked?

Static types are checked at compile-time.

> What's a "static type"?

Class types like Any, Int, Str, and users' classes.

Additionally, static subsets.

> What's a "static subset"?

Subsets are the subsets introduced by Ovid in the OP.

A _static_ subset is one that the compiler has decided to reduce to and treat as a finite set.

The compiler may treat Wday in the following code as a static subset and thus a static type:

        my enum Day <Su M Tu W Th F Sa>;
        subset Wday of Day where M .. F;

Currently Rakudo does not treat any subsets as static types.

> So what are dynamic types?

Subsets that aren't (treated as) static are (treated as) dynamic subsets and are thus treated as dynamic types. These are the _only_ dynamic types.

> Which code avoids dynamic types and hence is fully type-checked at compile > time?

All "untyped" code. Scalar containers ($foo, @bar[1], @bar[2] etc.) and values are assigned the static type Any. Of course this is pretty trivial but it is type checking and it does happen at compile-time. :)

Most if not all the code in the core libraries.

Most of the code in the ecosystem.

\----

I'd appreciate correction or wholesale destruction of any wrong ideas in the above. I'm particularly suspicious about methods. :)</comment>


Phrack issues 1-67, all in one PDF, seed  - <AUTHOR> http://thepiratebay.se/torrent/7064798/Phrc

<comment><USER2> Intriguing, now we just need more seeders.

</comment><comment><USER2> Thanks for sharing :)</comment>


The Chances of Another Chernobyl Before 2050? 50%, Say Safety Specialists - <AUTHOR> http://www.technologyreview.com/view/536886/the-chances-of-another-chernobyl-before-2050-50-say-safety-specialists/

<comment><USER2> The methodology for this forecast is wrong, the sample size is much much too small, and the conclusions about risks make no sense.</comment>