Science-Based Medicine Answering Our Critics - <AUTHOR> http://www.sciencebasedmedicine.org/answering-our-critics-part-1-of-2/ <comment><USER2> I appreciate the appeal to reason and evidence, but these arguments miss the root: trust. Many people don't trust the medical establishment. If more people did trust the medical establishment to consistently provide optimal treatments and self-correct in case of error, the whole nonsense over vaccines would never have happened.

And if someone doesn't trust you, look in the mirror. I mean, look hard. The authors of TFA look in the mirror, love what they see, and ask the reader, "how can you not love me too?"

<comment><AUTHOR> _And if someone doesn 't trust you, look in the mirror._

What do you do to gain trust if someone is continually spreading rumors about you behind your back?

[http://briandeer.com/mmr/lancet-summary.htm](http://briandeer.com/mmr/lancet- summary.htm)

<comment><USER3> Well, certainly you don't let things like this happen: [http://scienceblogs.com/insolence/2013/09/20/patients- endang...](http://scienceblogs.com/insolence/2013/09/20/patients-endangered- by-failure-of-medical-boards/)

<comment><AUTHOR> The author of that thoughtful blog post is, of course, one of the editors at Science-Based Medicine.

[http://www.sciencebasedmedicine.org/editorial- staff/david-h-...](http://www.sciencebasedmedicine.org/editorial-staff/david- h-gorski-md-phd-managing-editor/)

On his personal blog he uses the screen name "Orac," but he is the same person.

<comment><USER3> I guess the problem is that on the one hand he's imploring people to trust the science and those performing it, and on the other hand he's showing that those performing it aren't necessarily trustworthy.

It's hard for me to look at those two articles and reconcile the information from one of them with the information from the other.

Furthermore I have HUGE problems with people saying "LOOK SCIENCE!!" with anything other than physics or chemistry. In those areas where the interactions take place incredibly quickly and there are few compounding variables I love me some science just as much as the next guy.

When you start talking about organisms where everything is potentially a confounding variable it's a lot harder for me to excited about things being "proven" via science.

For example, fat used to be fine, then in the 80s and 90s it wasn't, now in the aughts and teens it might be again depending on which doctors you talk to.

I mean, right now you can't even tell if it's better to get small infrequent doses of no-sunscreen daylight (for the vitamin D) or not. The doctors and scientists are split on this one and there's no real discernable pattern as to which goes on which side. [http://www.skincancer.org/healthy- lifestyle/vitamin-d/the-d-...](http://www.skincancer.org/healthy- lifestyle/vitamin-d/the-d-dilemma)

Given that 10 years ago there was no debate whatsoever and now there's a huge debate raging it makes a person a bit circumspect when taking the advice of those who purport to "know" something.

</comment></comment></comment></comment></comment><comment><USER4> Although I do like addressing critics, I don't like this recent trend where critics of a particular science are treated with complete disdain. Is calling someone "batshit crazy", in so many words, supposed to open a dialogue?

For instance, the recent IPCC's attempt to make their position unchallengeable, with Tony Blair claiming No 'serious person' should doubt man behind climate change, says Tony Blair.

[http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1...](http://www.telegraph.co.uk/news/worldnews/northamerica/usa/10329520/No- serious-person-should-doubt-man-behind-climate-change-says-Tony-Blair.html)

So if you have any doubts or skepticism you are not a serious person.

Another example is the constant attack on anyone that claims GMO foods should probably be labeled and that they could lead to disaster if not treated with the proper scientific respect it deserves.

Here is an article from SciAm that claims basically that anything other than the status quo on GMOs is "hysteria": [http://blogs.scientificamerican.com/the-curious- wavefunction...](http://blogs.scientificamerican.com/the-curious- wavefunction/2013/09/06/scientific-american-comes-out-in-favor-of-gmos/)

I could go on and on listing public criticisms of science and their rebuttals, but my point is this - science is about challenge. We need to take a very careful approach when we're trying to convince _hearts and minds_ of the public and address their skepticism not with disdain but with empathy and understanding. Instead of saying, in a very eloquent way, "oh well, that's because you're stupid", we should stick to our scientific guns and beat down ignorance with facts. Going down any other path leads into the realm of philosophy, where science has no teeth. We can't simply wave our hand and say "trust us". Trust is earned. Let's earn it with science.

<comment><AUTHOR> You are not writing about the submitted article. The phrase you put in quotation marks is not found there.

<comment><USER5> People throw around "attacking a straw man" far too much, but it would be completely appropriate in the grandparent post.

<comment><USER4> I was trying to make a point that I summarized in the ending paragraph. I'm sorry you thought it was a straw man. My main point, if I can drill it further home, is not to _attack_ anyone in debate and instead use empathy to lead to a dialogue. For instance, say you meet someone that is against vaccines because of their supposed link to autism. Would it be better to talk to them rationally about the subject, figuring out why there is a lack of trust, while sticking to the facts, or is it better to call them out in public in a retort that makes them look childish? If you want to be _right_ then by all means, do the public retort. But if you want to convince them, then address them directly and stick to science.

<comment><USER5> Okay, on that point, I think it's fine to attack debate opponents as long as your are attacking them 1) on the merits of their points or 2) personal traits that are germane to the discussion.

The autism/vaccine link has been studied to death, far more than it should have been. It doesn't exist. But people still bring it up. Is that a good faith debate? I feel like the anti-vaccine discussion wants to be treated as an equal on a scientific basis, but is unwilling to do the hard work being aware of and understanding the research on the topic. I think they deserve to be treated with scorn, because a good faith effort to educate them has been happening for the better part of a decade and it has had little effect. Science is a bitch. If you don't get the answer you like, you don't get an unlimited number of do-overs.

EDIT: though, I think you have a legit gripe on GMOs.

<comment><USER4> Yeah, even the most compassionate person on the planet has limits to what debate it wants to entertain. I think we should stick to people that truly _want_ to learn the truth and ignore the ones that simply want to muckrake. Unfortunately a lot of people "learn" from pictures with quotes on them posted on a social network, and it just wastes everyone's time. It's up to us to either address it or ignore it. I'd rather ignore it and reach those that can be reached. Because unfortunately I've found that digging into a topic with people that parrot statements without much basis in fact that they lose all interest. How can you convince someone that philosophically believes that the world is out to get them, that they should stop talking and listen? This is the great challenge of science, as always.

</comment></comment></comment></comment></comment></comment><comment><USER6> "Neither can CAM. But doctors do have some pretty good ideas why it happens: exposure to infections, number of organisms that get into the body, genetic factors, _toxins_ , immune deficiency"

I would have preferred that they use the word poison instead of toxins. Not that it's factually wrong but a lot of woo treatments claim to flush the toxins out of the system.

Maybe I'm overly pedantic here, but a provider of dubious therapies can point to this very article and claim that "see, my mercury enema treatment flushes out the nasty toxins. Even scientists claim that this can be a problem".

<comment><USER7> I agree, the word is tainted by the association with woo-peddling. It has a real use and when speaking technically, or writing scientifically, the correct term should be used, but when speaking colloquially, I think we should avoid those words.

Reminds me of the word "believe". It should mean "you think it's true", but it has so many supernatural/unscientific connotations that people start using it as a trap "do you believe in global warming" which is just becomes a minefield of misused language and gotchas.

</comment></comment><comment><USER8> I would be interested to hear why they're "biased against using placebos because [they] consider it unethical". There is rigorous scientific support for the effectiveness of placebos in some situations, so by not supporting their uses they're effectively cutting patients off from a cheap, easy to produce treatment. Sure, lying isn't particularly ethical, but neither is denying a patient a valid treatment, so I wonder how they decided between the two.

<comment><AUTHOR> _I would be interested to hear why they 're "biased against using placebos because [they] consider it unethical"_

You quoted part of point 2 from the submitted article, and asked for more details. Point 30,

"30\. If CAM makes people feel better, why deny them that? Even if it's just a placebo, isn't that a good thing?

"That merits its own post, which will appear as Part 2 next week."

suggests that we will hear more about the answer to your question. The preliminary answer I would give is that most claims of "placebo" medicine greatly overstate the benefits of placebos. I have written about this previously here on HN,[1] with plenty of links to research articles.

[1] [https://news.ycombinator.com/item?id=4491460](https://news.ycombinator.com/item?id=4491460)

<comment><USER8> Thanks for pointing that out, I'll pay attention to their next post.

I skimmed over the content you linked, and it did suggest that placebo "can influence patient-reported outcomes, especially pain and nausea". It reminded me of this article: [http://www.thedailybeast.com/newsweek/2010/01/28/the- depress...](http://www.thedailybeast.com/newsweek/2010/01/28/the-depressing- news-about-antidepressants.html), which seemed to suggest a legitimate use case for placebo treatment.

</comment></comment></comment><comment><USER9> On the same token, any reader interested in the topic should read `bad science' by Ben Goldacre.

<comment><USER10> And the people at Science Based Medicine should address the legitimate criticisms in Ben's book Bad Pharma instead of focusing on the foolish woo from the alt health practitioners. I am sure its much easier to pretend that if the new age healers are wrong, then everything about the current use of pharmaceutical therapies is unquestioningly perfect.

The truth is there are serious problems with the current way drugs are researched and prescribed. So many people embracing non-standard therapies is a symptom of this, even though the average person may not be able to rationally articulate their concerns.

<comment><AUTHOR> The people at Science-Based Medicine have written a favorable review of the book Bad Pharma:

[http://www.sciencebasedmedicine.org/bad-pharma-a- manifesto-t...](http://www.sciencebasedmedicine.org/bad-pharma-a-manifesto-to- fix-the-pharmaceutical-industry/)

They were aware of those issues and mentioning them before the book was published. Ben Goldacre and the joint editors of the Science-Based Medicine group blog are largely on the same page about how to investigate the safety and effectiveness of prescribed drugs.

</comment></comment></comment><comment><USER11> Taking the time to explain things that should be common sense shows to me that they somehow really care about people's health. Less empathic people would just let natural selection thin out the CAM user population.

<comment><USER12> Or is it the science based population that will be thinned out? Taking into account iatrogenesis (look it up) basically anything that takes you away from a doctor will be beneficial to you. However, this does not apply when dealing with servere diseases. In that case you no longer need to worry about side effects and this is where science-based medicine really shines.

<comment><USER13> Nurse, he's escaped again!

What a load of old carp. Science based medicine has saved and prolonged so very many lives. Yup, some treatments have side effects. Sometimes these are fatal. However the balance is massively skewed in favour of SBM and getting more so all the time.

</comment></comment></comment><comment><USER14> Because you all love data so much: [http://childhealthsafety.wordpress.com/graphs/](http://childhealthsafety.wordpress.com/graphs/)

It's funny to me how the HNers who question vaccines remain silent when these threads pop here. I know they're out there and I know they read them all the time, just are too scared to respond. Guess I am too, with this throwaway and all.

<comment><AUTHOR> Better data on the issue you bring up:

"How vaccination saves lives"

[http://www.nhs.uk/conditions/vaccinations/pages/vaccination-...](http://www.nhs.uk/conditions/vaccinations/pages/vaccination- saves-lives.aspx)

"How vaccines saved millions of lives"

[http://www.skepticalraptor.com/skepticalraptorblog.php/vacci...](http://www.skepticalraptor.com/skepticalraptorblog.php/vaccines- saved-millions-lives/)

"Vaccines bring 7 diseases under control"

[http://www.unicef.org/pon96/hevaccin.htm](http://www.unicef.org/pon96/hevaccin.htm)

"Gates Foundation Annual Letter 2011"

[http://www.gatesfoundation.org/who-we-are/resources-and- medi...](http://www.gatesfoundation.org/who-we-are/resources-and-media/annual- letters-list/annual-letter-2011)

</comment></comment><comment><USER15> Trust is important!

see :"AbbVie representative says info on adverse effects of drugs should be considered commercially confidential" ( 6th September 2013 )

 _" On the other hand, there are other companies suing the European Medicines Agency to prevent release of clinical trial information. One of those companies, AbbVie, has just argued that information about adverse effects of drugs "is confidential commercial information because if released other companies could use it to help them get products approved." Watch Neal Parker of AbbVie say this at a meeting hosted by EFPIA, the European pharmaceutical industry body, in Brussels:

The Head of the Dutch medicines evaluation board asked Parker in response "You think that adverse events are commercially sensitive information? … You are aware that you are working in the healthcare industry, with patients and human beings?"

Hans Georg Eichler, the EMA's senior medical officer, said "I have been a regulator for many years and I am totally flabbergasted."

AbbVie representative Neal Parker went on to say that AbbVie will release information on adverse events to researchers who request it and who promise not to share it with competitors, on a case by case basis. This is what other companies do too. Other companies are not claiming that this is commercially confidential information.

If the views of those like AbbVie prevail and information from drug trials is kept behind closed doors doctors won't know it, researchers won't know it and patients will suffer. Sign the petition calling for all clinical trials to be registered and results reported and help us by donating to the AllTrials campaign."_

[http://www.alltrials.net/2013/2338/](http://www.alltrials.net/2013/2338/)

<comment><USER15> please sign the petiton :

 _" Around half of all clinical trials have not been published; some trials have not even been registered. If action is not taken urgently, information on what was done and what was found in trials could be lost forever, leading to bad treatment decisions, missed opportunities for good medicine, and trials being repeated unnecessarily."_

\---> [http://www.alltrials.net/](http://www.alltrials.net/)

</comment></comment><comment><USER16> "Only the scientific method can give us reliable knowledge"

Wrong. Math also gives reliable knowledge and has nothing to do with the scientific method.

Also remember that science had _proved_ light was a wave and not a particle. Until it was disproved. (Amongst other examples). And several "scientists" forget that what's 'true' today for science is the best answer from what's know today, but that may change in the future.

But more commonly, science is a concept. What we have contact with is the result of the application of that principle by researchers, which usually is close to the ideal thing, but sometimes is not.

"There is proof that X is correlated with Y (cites study).

Correlation does not prove causation"

This is important, and I would bet on a lot of studies implying the causation where there's none.

<comment><USER10> I don't think you have a clue what science is and I doubt I can thoroughly correct you in this short space but I'll give it a shot.

Math is a language - it has no inherent analogies to reality. It can be used to describe a natural phenomenon, but the validity of this description must be tested through experimentation. If it is not disproven, a mathematical (or other type) model can be a useful tool in simulating the observable world.

<comment><USER16> "Math is a language"

Beyond the fact that languages can be described in a mathematical way, yes.

And science is a philosophical concept. It also _does not have_ any formal verification towards the validity of it. It has certainly has had a practical success, but one could say that is even anecdotal.

<comment><USER10> A better way to say it is that math is a formal system - It is a set of symbols and rules for transforming those symbols. It is often mistakenly believed that it is the one and only universal system. But not long ago we used Roman numerals and did not even have calculus. (How Archimedes did his work I can't imagine.) What we consider modern formal mathematics is only one possible system and there is no reason to think that a completely different one would not do the same job just as well.

You use the terms "verification" and validity." These terms are used in symbolic systems to describe formulas that are well-formed (follow all the rules of their formal system) or equivalent to another formula (derivation) or a legitimate combination of multiple formulas (proofs.) Unfortunately, no matter how much you "prove" a pure mathematical theorem, it will never mean a darn thing about our observable universe. That is a job only science can do.

</comment></comment></comment></comment><comment><USER17> Replace CAM with a religion of your choice and most of the page reads just fine. Irrational reasoning in the face of contradicting scientific evidence looks the same, no matter the subject it seems.

<comment><USER18> The whole article kept reminding me of Tim Minchen's Poem "Storm". I think almost every point was covered, and it made me giggle :)

</comment></comment><comment><USER19> Puff Peace.

</comment><comment><USER20> I find it silly to try and disprove idiots who think some bogus alternative medicine works. Let the evolution take its course and weed out the morons.

<comment><USER12> Well, feel free to take any medicine you want, whenever something hurts or you feel depressed, basically every time you want to adjust any body function. Never mind side effects and let evolution take its course.

<comment><USER13> Because anyone that ever takes any form of medication doesn't live long enough to reproduce?

WFT are you on about?

<comment><USER12> it's not so much about the reproduction of the person as of the idea.

<comment><USER13> Then it has little to do with evolution.</comment></comment></comment></comment></comment>


Mock Interview Resources for Software Engineering Interviews? - <AUTHOR> Howdy ya'll, a little bit about me: I'm a rising senior aiming to go into software engineering after graduation, and currently preparing for full-time recruiting this fall. I've spent many hours on Leetcode, CTCI, and HackerRank to hone my algorithm skills.
The next step in the interview prep is to find a good mock interviewing platform, but I can't seem to find any. Only one I heard of is SoftwareTrain ( https://softwaretrain.gettechtrained.com/ ) , but they're new so don't know much about them. Do you guys know of any other ones?
Please comment which resources you guys are using for mock interviews. <comment><USER2> [https://www.pramp.com/](https://www.pramp.com/) (I really like this one and I use it weekly for my preparation)

[https://interviewing.io/](https://interviewing.io/)

[https://codesignal.com/developers/](https://codesignal.com/developers/)

</comment><comment><USER3> [https://www.interviewbit.com/invite/adggd](https://www.interviewbit.com/invite/adggd)

(I've used this to get my second job, pretty good for prep & mock interviews)

</comment><comment><USER4> You seem to very much focused on data structures and algorithms, which I do understand is the only way many organizations can quantify prospective programmers (other than knowledge of "technologies" and "languages").

I'm curious what your response would be to the following interview question ...

"How would you model into code the operation of an elevator?"

(I'm wonder whether your viewpoint is solely one of data structures and algorithms that transform them. Or whether you might also have some other perspective of how to go about approaching the design of a software application?)

<comment><USER5> The elevator question is deceptively difficult and I find there aren't any decent answers to it on the internet. People have devoted phd papers to this topic. And there are sparse Leetcode discussions on this subject.

<comment><USER4> I suggest it is particularly difficulty if you have no method or approach to apply. That in itself says a lot about an applicants design and programming ability. Given that much of software development is about modeling systems (real or imagined) into code, is it too much to ask that a "programmer" know something about it?

</comment></comment></comment><comment><USER6> Shoot me an email, I help people with mock interviews. Free, no bs, just paying fwd.

1 hour long, mix of technical and behavioural.

I interview people at my job.

</comment><comment><AUTHOR> I've tried mock interviewing with friends and it has been helpful, but I think mock interviewing a professional would be most effective

</comment><comment><USER7> Please add Ask HN: to the tile, it will be easier to find for the community :)</comment>


Why Computers Will Never Be Truly Conscious - <AUTHOR> https://theconversation.com/why-a-computer-will-never-be-truly-conscious-120644 <comment><USER2> Except maybe actual neuromorphic computers can, some observations hint that synthetic neurology might be a possible that can be scaled: [https://futurism.com/self-assembling-circuits-resemble- brain...](https://futurism.com/self-assembling-circuits-resemble-brain-stores- memories)

This of course, doesn't necessarily rule out digital emulations of the interconnected correlates given sufficient technologies to emulate it either though? Of course, it doesn't mean the computer science we have now will grant conscious computers, but computer science of the future still may.</comment>


Show HN: Open source guide for avg Joe to gain back his privacy - <AUTHOR> https://becominganonymous.com/ <comment><AUTHOR> This is not geared towards privacy experts but for avg internet user that might do some of the things mentioned and get him more interested and find out more about how they can have their privacy back.. here's the code if you want to contribute [https://github.com/surfer77/becominganonymous.com](https://github.com/surfer77/becominganonymous.com)</comment>


Interstellar communication using microbial data storage - <AUTHOR> http://www.thespacereview.com/article/3265/1 <comment><AUTHOR> A must read article by Mars Society founder Dr. Robert Zubrin. Quite intriguing proposition.</comment>


Wall Street Topped $100B in Profit for 2018 - <AUTHOR> https://www.bloomberg.com/news/articles/2019-01-16/it-s-official-wall-street-just-made-100-billion-for-first-time <comment><USER2> And my 401k topped a 15% loss.

<comment><USER3> And mine</comment></comment>


3D Video on Youtube. - <AUTHOR> http://www.youtube.com/profile?v=6RFuRY7azgA&user=smpfilms

<comment><USER2> Ow, the cross-eyed mode isn't so easy on the eyes and not sure how that would work. Anyone had better luck (and vision) than I did?

<comment><USER3> It's difficult at first, but many people who "freeview" (as it's called) find that cross-eye is the ideal way to view 3D images on screen.

An alternative is to do it Magic Eye-style, looking through the screen so your left eye sees the left image, and the right eye sees the right. This is hard to do with large images: your eyes more easily cross than diverge. To help view it crosseyed, try looking at your finger 4" from your face (you'll go crosseyed), then try to focus on the screen behind it while keeping your eyes trained on your finger.

There are other good things about this way: You get true full color, unlike with red/cyan glasses. Since both eyes are viewing a different set of pixels, the resolution is effectively doubled, so the image appears sharper than normal.

</comment></comment><comment><USER4> I didn't get it?? Something wrong with my eyes?</comment>


HP Promises Fix for Time Bombing Unofficial Ink Cartridges in Its Printers - <AUTHOR> http://abcnews.go.com/Technology/wireStory/hp-promises-fix-printer-software-barred-ink-42430919 <comment><AUTHOR> I have a tip for companies like HP that prevent cloned ink cartridges from working in their printers: You should _secretly_ sell your own official cartridges as cloned cartridges at a discount price -- as well as continuing to sell the official cartridges at the rip off prices.

That way, you'll capture the high profit on those people who pay for the official cartridges as well making some money on the "cloned" cartridges.

It would be a little embarrassing for them it was discovered, but it wouldn't be the first time a company had wildly different pricing depending on the marketing channel.</comment>


Cross-Database Queries in Azure SQL Database - <AUTHOR> https://azure.microsoft.com/blog/querying-remote-databases-in-azure-sql-db/ <comment><USER2> Good article explaining how cross db queries work in the azure SQL world

</comment><comment><USER3> Cross-Database Queries on Azure SQL Database! This will be so helpful!

</comment><comment><USER4> Cross-database queries add a powerful dimension to Azure SQL Database</comment>


Don't read the comments - <AUTHOR> http://arstechnica.com/science/2013/01/dont-read-the-comments-online-communities-shape-risk-perception/ <comment><USER2> Very Interesting dude.</comment>


VM Escape: QEMU Case Study - <AUTHOR> http://phrack.org/papers/vm-escape-qemu-case-study.html <comment><USER2> I think there is too much cruft in Qemu and a simple install can pull in hundreds of dependencies. For instance if you just want to run x86_64 VMs there is no point getting 20 different platforms.

For the standard run of the mill VM there is also rarely any need for the multitude of devices. The more stuff you put in the more surface area for exploits. The Qemu install candidate needs to be seriously redesigned and pruned down by package maintainers.

Intel Clear Linux tried running VMs without qemu altogether with Kvmtool but are now using 'Qemu lite'. But there are no packages, instructions or even a readme on what exactly they have done to make 'Qemu lite'. Kvmtool is one of those packages with zero documentation.

Libvirt is needlessly convoluted and its usage complexity has led to an inferior solution like Virtualbox gaining traction on Linux, inspite of kvm in the kernel. For those looking for a simpler way to use kvm I suggest trying something like Aqemu or even just resorting to the command line. I found it far more lightweight and reasonable than libvirt's heavy handed way of running a simple qemu-kvm command line and adding an XML mess to it.

<comment><USER3> Please don't make suggestions like "libvirt is too convoluted, just resort to [QEMU] command-line" \-- FWIW, I'm saying this as an _every_ day QEMU command- line user -- without having the complete picture. Yes, there _are_ some valid scenarios where people who know what they're doing _can_ (and they do) directly use the QEMU command-line. But for the most majority, libvirt makes life far simpler, because of the following.

Daniel Berrangé (lead maintainer of libvirt) articulates it much more succintly than I could, allow me to quote him:

"It is a common attitude among people who look at QEMU and see a deceptively simple command-line syntax for launching a VM and don't realize that you'll enter a world of hurt when you go beyond the initial simple command-line syntax.

This[1] was written in 2011, but is pretty valid and probably more besides:

      https://www.berrange.com/posts/2011/06/07/what-benefits-does-libvirt-offer-to-developers-targetting-qemukvm/

Recently, we had a very nice example of benefit of libvirt to security when the VENOM bug came out. Anyone using libvirt automatically had anti-VENOM available thanks to SELinux/AppArmour which would prevent exploitation in most cases."

More on it (from his very detailed response on this thread[+], specifically from the 4th paragraph on):

"Also note that this kind of bug [VENOM] in QEMU device emulation is the poster child example for the benefit of having sVirt (either SELinux or AppArmor backends) enabled on your compute hosts.. With sVirt, QEMU is restricted to only access resources that have been explicitly assigned to it. This makes it very difficult (likely/hopefully impossible[1]) for a compromised QEMU to be used to break out to compromise the host as a whole, likewise protect against compromising other QEMU processes on the same host. The common Linux distros like RHEL, Fedora, Debian, Ubuntu, etc all have sVirt feature available and enabled by default and OpenStack doesn't do anything to prevent it from working. Hopefully no one is actively disabling it themselves leaving themselves open to attack...

[1] I'll never claim anything is 100% foolproof, but it is intended to be impossible to escape sVirt, so any such viable escape routes would themselves be considered security bugs. "

[+] [http://lists.openstack.org/pipermail/openstack- operators/201...](http://lists.openstack.org/pipermail/openstack- operators/2015-May/006947.html)

<comment><USER2> I think you are presuming here about the 'complete picture'. The point is not to encourage anyone. I am sure people can make their own decisions.

We need to highlight the issues with libvirt that leaves a great technology like kvm unused. Security can be used to close down any discussion but the result is many people are using virtualbox and not libvirt.

Seccomp, selinux or Apparmor can be used without libvirt as required so I don't see this as a security issue. On the contrary the needlessly complex XML config files likely put many users off from using it properly or using it as all.

<comment><USER3> You are simply overstating the issue. Was not closing the discussion down with security -- that line of thought didn't even occur to me.

The `virtual-box` equivalent in the KVM stack is `virt-manager` (under the hood, it uses libvirt APIs) -- these are primarily for _desktop_ Virtualization, not for server Virtualisation. To manage a fleet of servers in a data center, people don't fire up a desktop application.

Can some aspects of the experience with `virt-manager` / libvirt stack be improved? Certainly yes. But saying things like it "leaves a great technology like kvm unused" is ridiculous hyperbole.

A clarification about _why_ it is partly a "security issue": The sVirt guest confinement mechanism in libvirt _builds_ on top of basic SELinux / AppArmour confinement. As in, with sVirt: each VM (the QEMU proces that is managed by libvirt) and its associated disk gets a _unique_ SELinux label -- this means, _even_ if a guest (in a fleet of 1000 VMs) is compromised, it is contained to just _that_ specific guest.

<comment><USER2> I think you are conflating issues here.

Obviously virtualbox users do not need data center level security and should not have to deal with that complexity, and naturally choose not to, and use virtualbox.

You have turned a simple observation about the complexity of libvirt's configuration and the resulting traction of virtualbox on Linux into a discussion on data centers, 1000's of VMs, and security. This seem to be talking around the issue so this discussion is moot.

Are you saying selinux, apparmor and seccomp cannot be used on qemu processes without libvirt?

<comment><USER3> You made a sweeping generalization about libvirt's complexity, and characterized it as a "simple observation", without any concrete pointers.

And you seem to be comparing Virtual Box with libvirt, which is equivalent to comparing apples to aardvarks (okay, that's an exaggeration). But seriously, a fairer comparison would be Virtual Box vs. Virt-Manager on Linux.

 _Here_ , I admit -- I'm not a daily Virt-Manager user (I live on the command- line), so I can't tell you where exactly it is lacking compared to Virtual Box.

If you've tried it, & have suggestions, you might want to write to:

[https://www.redhat.com/mailman/listinfo/virt-tools- list](https://www.redhat.com/mailman/listinfo/virt-tools-list)

\---

About the libvirt's _internal_ representation (in XML -- yes, I'm not a big fan of it either, and I suspect, nor are the current maintainers; had it been today, they would've likely chosen a more gentler-on-the-eye format like JSON or some such) of guest definition: Most users _don 't_ need to touch the XML definition at all. Most tasks that are involved in managing VMs can all be done trivially via Virt-Manager GUI, or the command-line, _virsh_.

And the _regular_ libvirt configuration files are all in standard Linux configuration file format.

> _Are you saying selinux, apparmor and seccomp cannot be used on qemu > processes without libvirt?_

No, I'm not saying that. My argument (based on daily interactions with users on public IRC & mailing lists) is that, for QEMU-based guests, libvirt makes it _easier_.

<comment><USER2> I think the issue here is I am more interested in understanding why virtualbox has so much traction on Linux inspite of kvm and you appear to be more interested in defending libvirt.

You have taken this discussion to unrelated security and data center issues that have got nothing to do with the topic on hand. You dwell on the security of seccomp, selinux and apparmor that have nothing to do with libvirt specifically.

I am not interested in discussing libvirt, virsh or virt-manager and its various offshoots. And given libvirt is the what virsh and virt-manager use in the context it's disingenuous pedantry to make a distinction.

I am interested in understanding how kvm can be made more accessible to virtualbox users. If that's not something that concerns you and you would rather dwell on defending libvirt then that's not a productive discussion. If libvirt was the solution we would not be having this discussion to start with.

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> If for some reason using QEMU with potentially hostile code (not recommended!), disable all the hardware emulation you can!

<comment><USER5> Pretty much all cloud providers that use KVM (where "pretty much all" probably means all except Google) are using QEMU and potentially can be running hostile code, so the "not recommended" remark is perhaps a bit exaggerated.

<comment><AUTHOR> What do they use at Google?

<comment><USER6> Some proprietary code replacing qemu (but still using KVM). Since they still have to emulate PC devices, this just means they have a different set of security holes and fewer people reviewing the code.

<comment><USER7> Given QEMUs track record, I'd wager that the goog code gets more reviewers and more testing. QEMU is literally swiss cheese, or it emulates real swiss cheese, poorly.

<comment><USER5> Any proof of what you are saying, or is it just FUD?

Most QEMU CVEs are related to devices that should never be used in cloud provider scenarios (you'll often find that they are disabled in RHEL for this exact reason). If anything, prompt handling of vulnerabilities in those devices is a sign of taking security seriously...

<comment><USER8> QEMU is a 14 year old codebase designed for research and cross-platform emulation. It is not developed with a focus toward ongoing security testing/auditing.

Xen uses a stripped-down QEMU to boot unpatched guest OSes. However, even Xen doesn't test its qemu-xen components extensively. Writing a new purpose-built emulator (assuming you know what you're doing) is a better idea.

edit: Or use PV guests, and skip all potential QEMU flaws.

<comment><USER6> Sorry, this is completely wrong FUD. Paolo Bonzini and I work at Red Hat and there is constant review of the QEMU codebase, both for code quality and security issues. Furthermore devices in RHEL are whitelisted. TCG ("cross- platform emulation") is not involved at all when you're using KVM. A newly written emulator would just have a new set of vulnerabilities. When you don't know what you're talking about, please just don't.

<comment><USER8> I'm glad to hear that! When did you implement fuzzing coverage? After the 2016 Qemu mailing list article I read where they're asking someone to look into applying to Google's oss fuzzing project? And how does your whitelisted set compare to Xen's stripped-down qemu support?

<comment><USER6> I'm actually fuzzing qemu's block device layer as we speak.

From the latest run:

        │        run time : 11 days, 23 hrs, 12 min, 49 sec    │  cycles done : 0      │
        │   last new path : 0 days, 12 hrs, 55 min, 7 sec      │  total paths : 364    │
        │ last uniq crash : none seen yet                      │ uniq crashes : 0      │
        │  last uniq hang : 0 days, 4 hrs, 4 min, 36 sec       │   uniq hangs : 2      │

Re the comparison with Xen's qemu, you can grab the sources for RHEL's qemu- kvm and qemu-kvm-rhev packages and examine the driver whitelists, patches and ./configure line yourself.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> With all the bugs in hardware emulation, wouldn't it make sense to emulate the linux kernel a la bash for windows instead of running the linux kernel on emulated hardware?

<comment><USER10> Sounds like you are describing containers; while not emulation neither is virtualization. There are many more opportunities for escape dealing with Linux containers than virtualization due to the increased complexity of the interface.

While I'm impressed by the work Microsoft have done to support the Linux kernel interfaces I would imagine the complexity of the effort to implement correct behavior from Windows kernel primitives would lead to more potential security vulnerabilities.

Another comparison might be Linux syscall support within illumos[1] which AFAIK relies on mature Solaris Zones for isolation.

[1] [https://www.slideshare.net/bcantrill/illumos- lx](https://www.slideshare.net/bcantrill/illumos-lx)

<comment><USER11> _Sounds like you are describing containers; while not emulation neither is virtualization._

Another possibility would be User-mode Linux (UML), in contrast to containers, it gives each 'virtual machine' its own Linux kernel, where the Linux kernel runs as another Linux program.

</comment></comment></comment><comment><USER12> This is a case of legacy code left in an important attack surface. I doubt many people need a virtual floppy drive today.

<comment><USER13> Nonsense. I use the virtual floppy drive in VMs all the time, because I'm virtualizing legacy systems. But I do agree it could probably be disabled (and thus unexploitable) by default.</comment></comment>


Ex-Sun vet Bray joins Google, declares Apple evil - <AUTHOR> http://blogs.siliconvalley.com/gmsv/2010/03/ex-sun-vet-bray-joins-google-declares-apple-evil.html

<comment><USER2> I find this to be slightly hypocritical, since Google has had its share of evil, while perhaps not as evil as Apple has been lately.</comment>


Kazakhstan bans anonymous comments on Internet - <AUTHOR> https://m.akipress.com/news:600404/& <comment><AUTHOR> It was a lot of negative comments about government and president himself. Thats how they solved the problem...</comment>


Brain can't handle more than 150 Facebook friends - <AUTHOR> http://timesofindia.indiatimes.com/life/health-fitness/health/Brain-cant-handle-more-than-150-Facebook-friends-/articleshow/5495127.cms <comment><USER2> Spotting regurgitations of Dunbar's number would make a fairly good drinking game. Bonus points when Dunbar repeats himself.

</comment><comment><USER3> Given how plastic the brain is I suspect that the limit on social relationships is more logistical than physiological.

ie actually meeting, being social for long enough to develop a relationship and then maintaining that relationship with someone takes a certain amount of time. Above a certain number of relationships the individual simply doesn't have the time or incentive to acquire more.

If there was a real incentive for someone to have more than 150 relationships I would expect that either a), their brain would rewire itself somewhat to handle the increased number or b) they'd make abstractions that would help them to maintain friends more efficiently.

</comment><comment><USER4> Apparently they haven't ever met the brain of a teenage girl.

</comment><comment><USER5> Monkey sphere: <http://www.cracked.com/article_14990_what-monkeysphere.html>

</comment><comment><USER6> Facebook might be a way to circumvent Dunbar's number. Knowledge is stored on computers, rather than in your brain, and you can decide to retrieve it if needed.

</comment><comment><USER7> Flagged. Too little content.</comment>


An Updated Analysis: Why SOPA & PIPA Are A Bad Idea, Dangerous & Unnecessary - <AUTHOR> http://www.techdirt.com/articles/20120117/23002717445/updated-analysis-why-sopa-pipa-are-bad-idea-dangerous-unnecessary.shtml

<comment><AUTHOR> I know there is _a lot_ of HN activity on this, today.

My reason for _yet one more_ link: This is a link I'm sharing with my friends and family who are less technical and/or less informed on the topic.

techdirt's writing here, and consistently, has been eloquent and elucidating. And their linking lets the reader quickly and conveniently dig as far into details and background as they might desire.

I've been devoting a significant portion of my time in recent weeks and today to offering such information to my contacts who might be concerned but have remained largely uninformed. I hope we all can devote some personal time and attention to doing so, today and in the coming weeks (for this isn't over, and we need a bulwark of public education to slow down both this specific legislative initiative and the future ones that are surely coming).</comment>


Airbus A380 – $6.1B in additional costs due to project delays - <AUTHOR> http://calleam.com/WTPF/?p=4700 <comment><USER2> There is a bigger problem. The growth of ETOPS planes (planes with two engines that can fly over the Atlantic or Pacific) with fewer seats that need to be filled for a route to be profitable have basically made this plane irrelevant. This includes the 787, the 777, and Airbus's own A350. Airbus greenlit the project based on original sales projections of 1,200 A380s being sold. So far around three hundred have been sold. In addition Airbus projected a brand new market called "VLA" (very large aircraft >500 seats) would come into existence and demand sixty to seventy airframes a year. They therefore compromised the original design of the A380 to target a re-winged and re-engined stretch version down the line. So far most carriers run under 500 seats, with no-one even coming close the theoretical 850 seats that the current Airbus could do, to say nothing about a next generation A380.

Airbus explicitly bet that point to point routes would go away in favor of fortress hubs and hub to hub traffic. The reverse has instead happened. United is making a small fortune now with hub to previously unserved cities in Asia. Norwegian is disrupting the entire Atlantic market by flying 787s into other carriers hubs, destroying any economic advantage that the hubs have.

Airbus wanted plane that was "the biggest and the best" for prestige purposes. That led them to green-light the A380. The A308s engineering problems are problems, but what ultimately dooms it is a basic conceptual problem with the plane itself. It's basically a prestige project, and is going to leave Airbus and European tax-payers on the hook.

All that said, the A380 is a great plane to fly on. I fly it regularly to Bangkok via Seoul. More often then not, the entire upper deck (which is business only on Korean) is 75% empty.

<comment><USER3> I call the A380 the Flytanic. It's not even a very atrractive plane. The 747 is retro now, but it is a beautiful plane. Whenever I can, I fly the 787 on long haul flights. Super comfortable, love it.

<comment><USER4> I recently flew economy in a 787 for the first time and it was the most uncomfortable flight I've ever had. Incredibly narrow seats, and way too much cabin noise. I have heard the same thing from other people.

I wish airlines would charge a bit more per seat instead of trying to keep shrinking the seats. As it stands you have to pay a lot extra in many cases to get a comfortable seat.

<comment><USER5> You must have been on JAL 787. The economy seats there are incredibly tiny. I assume this is because Japanese people are not big.

</comment></comment></comment></comment><comment><USER6> "Internal reviews identified that the heart of the problem was the fact that the different design groups working on the project had used different Computer Aided Design (CAD) software to create the engineering drawings. The development of the aircraft was a collaboration between 16 sites spread across 4 different countries. German and Spanish designers had used one version of the software (CATIA version 4), while British and French teams had upgraded to version 5."

Really interesting! While I've hardly worked on anything as complex as an A380, I take it as a high priority for all software packages, from dev to test to prod, all be on the exact same version. Python 3.4 on one box and 3.6 on another? Let's not.

<comment><USER7> Several years ago I worked with a large multinational company where every site had their own IT teams. A lot of mergers, etc. Probably much like BAE. A firm who's major product is info.

Some of those teams were extremely incompetent.

My client had made a video of the CEO speaking to the whole company which turned out wouldn't fit on their internal sharepoint site because there was a 50 meg limit for videos. The CEO was not at all impressed with the quality of a 20 min video at 50 meg so in desperation, they ended up asking us to host it for them.

But then vimeo didn't work for some sites, then wistia for others, in the end we ended up having to set it up on Amazon's cloudfront. So each site had their own firewall rules, own white-lists, bad IT connections, etc.

Throughout this debacle, we got claims of _our_ incompetence by IT personnel at their various sites. Really opened my eyes at how disorganised a large organisation can become, as well as how people can hold positions in large orgs that they have no ability to perform by politicking.

And that's how you end up with loads of different versions of software at different sites in the same company.

EDIT: Actually, I recall incorrectly, we originally used cloudfront, which didn't work, then vimeo was blocked on some sites, but no-one had blocked wistia yet as they were still a fairly new entrant.

Random endorsement: Wistia are great, love their API, love their support, great video hosting company.

<comment><USER8> I see the same at my company. I think the reason is that the top guys in non- IT industries don't see IT as core competence but as a cost center that ideally gets outsourced to the lowest bidder. Unless there is a very strong CIO different divisions won't talk to each other and no standardization happens. Even if one division does a good job they usually can't sustain that for long because their budgets will get cut. It's a very unhappy situation for everybody and the best people leave after a while.

</comment></comment></comment><comment><USER9> The article states that calculation of bend radii (of wiring/cabling) was the problem. If that was the case, surely one of the two versions of their design software was calculating incorrectly? If so, one would think that the whole team being on the same version wouldn't have helped (if they were on a version that calculated lengths incorrectly).

But perhaps there's more subtlety to the calculation discrepancy than is evident in the article.

</comment><comment><USER10> > ... when the A380 Program Manager attempted to move the German designers > onto the same CAD system as the French, he met a wall of resistance. > Personal rivalries and national pride are reported to have been issues ...

And yet there are other, more objective motives for resistance. As all big-org managers know:

1\. Reputational: Belatedly switching to your peer organization's tools suggests you made a poor planning decision earlier.

2\. Work shifting: The switch itself will inevitably consume many weeks of calender time, though non-technical upper management will insist on pretending otherwise. While you're struggling to switch, the rival peer org will press its advantage, collecting milestone checkoffs and praise from higher-ups. Alternative is to block the change, so as to bury some considerable share of the tool mismatch pain and delay in the rival org.

</comment><comment><USER11> Talk about burying the lede:

> In today's complex integrated supply chains, stories of failed configuration > management during the design process are a sadly all too common.

This is a good way to kill a lean and virtual startup, and surely has.

Also fascinating: the manager who raised the problem in the first place was blocked by upper management and then fired because the problem occurred.

</comment><comment><USER12> I admit I know virtually nothing about the aircraft industry, but I always wonder why Airbus doesn't do the initially planned cargo version of the A380. The only reason I can imagine is that there aren't enough customers for the cargo version, but why is this so? Isn't air cargo growing? Would an cargo A380 be too expensive? Some comments suggest the A380 has bad fuel efficiency per passenger mile, but some others suggest this is because airlines put less passenger seats in the plane than possible. Surely this can't be a problem for freight planes? What is it?

<comment><AUTHOR> Apparently it's about the weight/space ratio which makes is not economical to fly cargo with A380:

"An A380-F would be too fat to fly at a profit: The plane would hit the maximum payload (a constraint of weight) before its maximum cubic space (a constraint of volume). Its design can't support the maximum payload required to generate a profit.

(...)

The A380-F would be able to carry 60% more volume than the 747, but only 28% more weight. It wouldn't be fully loaded at typical levels of air cargo density, or at least nothing close to what can be supported by the thrust capacity of the 747."

[https://www.flexport.com/blog/airbus-a380-no-cargo- equivalen...](https://www.flexport.com/blog/airbus-a380-no-cargo-equivalent/)

</comment></comment><comment><USER13> Most comfortable passenger aircraft I've ever flown on. I've only flown them with Emirates - and it may be a combination of their choices for how it is equipped inside along with their service, but either way if I ever have a chance to be on an A-380 I jump at it.

<comment><USER14> How does it compare to the Dreamliner/Boeing 787?

I like the Dreamliner. The ride is noticeably smoother and the improvements to cabin air filtration, humidity management, cabin pressurization at lower altitudes, larger windows, and "mood lighting" make for a more enjoyable ride [0].

[0][https://backpackerlee.wordpress.com/2014/08/28/the- airbus-a3...](https://backpackerlee.wordpress.com/2014/08/28/the- airbus-a380-vs-the-boeing-787-dreamliner/)

<comment><USER15> All nice bonuses when you've got your knees in your nostrils and elbow locked with the person next to you. Almost all 787s joining fleets have smaller width or legroom than their replacements (whatever they are a380, 777, a330 etc..). There are exceptions Air India is one and I forget the other..

<comment><USER15> A little late addition, also consider watching the documentary Broken Dreams 787 by Al Jazeera, it is available on YouTube, some very concerning allegations that go far beyond limited space.

</comment></comment></comment></comment><comment><USER16> Don't write it off.

1\. They say the plane may have been "10 years too early"

2\. It will get more fuel efficient engines.

[https://translate.google.com/translate?sl=it&tl=en&js=y&prev...](https://translate.google.com/translate?sl=it&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.welt.de%2Fwirtschaft%2Farticle140020669%2FDer-A380-wurde- wohl-zehn-Jahre-zu-frueh-eingefuehrt.html&edit-text=)

<comment><USER17> All planes will get more fuel efficient engines. Direct routes are likely to remain dominant.

<comment><USER16> Where? In the US?

I am not sure this is the case in markets with hight growth rates.

</comment></comment></comment><comment><USER18> It also important to point out that a lot of airports (for example, Dublin) are not equipped to actually be able to manage the A380. Where as a lot are capable of the 747.

<comment><USER19> An addendum to your point: Aer Lingus (the Irish Flag Carrier) used to fly the 747 out of Dublin.</comment></comment>


Why not have Lego like Software? - <AUTHOR> Hi Folks,
Really enjoy the HN great community with so much knowledge and enthusiasm, been lurking for a long time just reading the stuff you folks share and discuss, i could go on and on :) but need to keep it short...
Consider I am simply asking a question and no implying anything, rather just wondering...
Would it be possible or rather better if we built software in a Lego like way, Particularly i was wondering about Linux and some other tools (audio players, etc, etc)
I understand that all the distros do things in their own way, but at the same time share a common Core (correct me if i am wrong) Kernel, then different groups build things around it.
Why not unify those groups and make them work on the Shared Components and Individual - ill try to explain...
Imagine Having a Single distro which once you install the Core on your Computer asks you Which group you belong?
-Musician -Scientist
-Education -Artist - Developer
etc.
Based on that it installs the UI + Tools for that domain, Where also if needed be Switching from a Domain to Another Domain just removes all the packages and then asks again what you wish to add
Just like Plugins for IDEs
Wouldnt it make the Software more Robust and also everyone gets to work and build his own vision + make the shared core much more reliable, I have been thinking about this and wondering about it, also been reading and searching but havent found the answer i was looking for really, I might have also skipped a few details on what i was going for, but i guess you who are versed in this topic would Elaborate more on it and give your comments.
Looking forward to the answers :) (if the title is wrong suggest a change, be glad to update to attract more thoughts and discussion, Reading suggestions welcome, Books, podcasts anything...)
Thanks <comment><USER4> Lego works the way it does because one company is responsible for producing every single little plastic brick. The Lego company takes great pains to control the precision of their manufacturing process to ensure the bricks click together. If you worked for Lego and you designed a piece that did not connect to any other pieces, they would not produce it. It seems obvious this approach cannot work over the whole world. However, I think if you look at software made only within a single company I feel like you _do_ see this principle in action, frequently.

Also, Linux distros themselves _are_ the domain-focused packages you want, all built around the "core" of the Linux kernel. There are various "distro building" projects that approach this configuration problem from varying levels of abstraction, e.g. Damn Small Linux, Ubuntu Builder, or NixOS.

<comment><AUTHOR> I agree, its clear from the Corp companies, that is why i cant stop wondering about the focus of developers, why each month we get a new framework, new project that tackle the same or similar project as an already existing project. Why not get together and let the best idea win, too often do i read about philosophies and differences, one such i would mention Debian vs Devuan

Full disclosure i am not a Software engineer or architect

Thanks

<comment><USER5> Because not all solutions work the best for all problems.

</comment></comment></comment><comment><USER6> That's essentially what a package manager does - there are even such groups as you suggest.

It does differ from Lego because of the complexity - multiple orders of magnitude, in fact; and another thing: everything made of Lego has a distinctive Lego-style. That's perhaps another driving factor: "that style looks ugly, we will build another, nicer and more fluid."

<comment><AUTHOR> But why not work collaboratively to improve the existing one? I understand the package manager, please if possible share the groups links or anything pointing in the direction, i would like to explore. Thanks

<comment><USER7> Possibly, the BSD community is more like what you're looking for. It may be a matter of top-down vs bottom-up philosophy (i.e., control).

<comment><AUTHOR> I asked the question because of Distro Watch, i was always wondering why are there so many Linux Distros, why not work on just a few Distros United, while enabling the modularity where each group would have a piece of their vision while enabling the users to chose which one they would use,

could this fragmentation be the cause for the lack of Linux presence on the Desktop?

Rather than uniting the forces, and building experiences on top of functionality, they each build their own experience their own way in hopes of attracting users...

Thanks

<comment><USER8> I'd say this is due to

\- disagreements/factions

\- wanting the satisfaction and validation of building something yourself

\- implementational conflict with existing systems

Sometimes the validation thing is due to ego, sometimes it's because the journey of building a new system is useful in itself.

In the case of the distro I want to create (:P) it's because the (very simple) ideas I have conflict with the way things are commonly done, so I'm going to have to set out on my own. It'll be fun though. Users in my case will be a headache because then it won't be a fun personal project. I just want to solve my own frustrations.

And "Linux on the desktop" has been a meme for years. It'll never happen until Linux achieves cohesiveness, aka never, full-stop. (Took Microsoft a while to figure that and build WSL...)

NB, I don't see an email or other contact details in your bio. I could let you know when I finally do get around to starting w/ that distro.

</comment></comment></comment></comment></comment><comment><USER9> At root, philosophically (as opposed to practically), are you not describing this: _A Pattern Language_ , Christoper Alexander, 1977, [https://en.m.wikipedia.org/wiki/A_Pattern_Language](https://en.m.wikipedia.org/wiki/A_Pattern_Language)

Yes, it's not as blocky and snap-together as Lego, but I always considered that an artifact of the need for adaptability/evolution, flexibility to allow things to fit into environments of random complexity, and accommodating a wide array of human preferences.

"Programming", like architecture/planning of the physical environment, seems to have turned out to need this degree of granularity, nearly indistinguishable from an organic system.

<comment><AUTHOR> Seems like a great read, thanks :), book on the way...

<comment><USER9> Good call. I'd put it in a top 100, even top 10, for post- zombie/Trumplightenment civilization rebuild.

<comment><AUTHOR> Please do share any other reads :), thanks

<comment><USER9> OK. It doesn't really go to your original post, but I often also point people to _The Design of Everyday Things_ , Donald Norman, 1988, [https://en.m.wikipedia.org/wiki/The_Design_of_Everyday_Thing...](https://en.m.wikipedia.org/wiki/The_Design_of_Everyday_Things)

Basic insight into the question of: "What makes a good tool?" Maybe for your purposes, the angle is: "When is a simplified tool more useful than a complex one?" Or: "How can I add complexity to a tool while preserving its usefulness?"

</comment></comment></comment></comment></comment><comment><USER10> Doug McIlroy, the inventor of UNIX pipes is quoted as "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.".

I know it's probably not exactly what you're looking for but "Do one thing and do it well" tools and UNIX pipes to connect such single-purpose tools in my opinion is quite close to a "pluggable building blocks" metaphor.

In terms of web applications the REST paradigm and data represented as JSON structures is a similar smallest common denominator.

Someone else has already mentioned Christopher Alexander's pattern language approach. Design patterns and Atomic Design are similar concepts for the software development domain.

<comment><USER11> This is the real value of microservices, in my mind. It allows you to create services that "do one thing and do it well," including deployment considerations like the degree of autoscaling or load balancing required by some components and not others.

Totally unrelated, it is also why I think "full stack developer" jobs are just business junk and should be totally avoided. Business people wishing for "full stack" employees are like a giant red flag of a business full of dysfunctional complexity mismanagement, without a clear vision of what needs to be solved.

Inside of a software system, if we organized one monolith class or one monolith webservice that was "full stack" in the sense that it had responsibilities cutting across lots of disparate systems or layers of the stack, we would rightly think this is a bad software design, rife with unnecessary complexity from trying to make certain components do too many things. And probably it would be reflected in how hard it is to refactor, extend, or write clean tests for such a system.

I argue that popping up one layer outside of the software system and into the realm of the organization of engineers who design and implement it, we should still think the same way. Different employees should be isolated specialists in certain parts of the system, and should not be expected to have cross- cutting "full stack" job duties, which is really just a way for companies to artificially save money on headcount (artificially, because the lack of clean separation of concerns ends up costing them more money in the end).

This is not a statement that a given engineer should not learn about broad aspects of system engineering. It's always good to diversify your knowledge, have a better picture of the meaning of the work of other teams, or be able to fill in during an emergency or something. Only a statement that an employee's nominal job duties should not include vague bottomless complexity buckets reflected by "cross functional" or "full stack" responsibilities.

This dysfunction is also often described with the "wear many hats" bullshit, where the same person who is expected to design a performant machine learning backend system is also expected to create a responsive single page website and write any CRUD implementation, ecommerce shop logic, auth logic, etc. etc., all while also functioning as a devops engineer and a data pipelines engineer because "wear many hats."

It's the same mistake that Single Responsibility Principle is meant to guard against, just at the level of programming teams of people instead of programming components of a software system.

<comment><USER10> From my point of view, the main benefit of microservices is risk reduction. Microservices allow you to iterate rapidly and roll out new features without potentially affecting your application as a whole.

"Do one thing and do it well." can also be an argument for using microservices. However, your application has to be of a certain size in order for that to be a valid point. If your application merely has a few endpoints, most of which are rarely - if ever - used as each other's inputs, then using microservices only adds development overhead without yielding considerable benefit. This is also why I'm critical of the surprisingly common one-size- fits-all "Use microservices for everything" approach. Microservices are just another design pattern. They're not a cure-all for every software development problem.

I, for one, am doubtful about the front-end / back-end developer dichotomy because it tends to create new silos. I don't particularly like "full-stack developer" either because I think engineers should aim to be problem solvers rather than people who merely turn someone else's solution into code.

Solving a particular problem in some cases might just involve the back-end or the front-end but in most cases it not only involves both but other areas such as requirements engineering or design as well.

<comment><USER11> > "From my point of view, the main benefit of microservices is risk reduction. > Microservices allow you to iterate rapidly and roll out new features without > potentially affecting your application as a whole."

I think this is the same reason why "do one thing and do it well" is useful in software components or shell utilities too.

Basically, what you said about microservices is just a restatement of Single Responsibility Principle / decoupling, in general, and it's not unique to microservices.

In this sense, I'd say microservices are not a design pattern. Rather, it is an organizational strategy for minimizing the risks of coupling _in other design patterns_ , which is also why microservices are explicitly a good idea in cases when a service might only have a few independent endpoints.

I don't buy the argument that it adds overhead. In fact I'd say it explicitly reduces overhead, because the boilerplate of wrapping it in a web service is just too tiny to care about compared with the overhead required to manage the complexity when a system tries to be responsible for too many things.

In other words, I think good hygiene would say defaulting to microservices is the right idea, and consolidating should require evidence that it provides the expected benefits.

Personally I am reminded of the funny Andrew Gelman quote, "Just because something is counter-intuitive doesn't make it true."

I think it's fashionable to criticize microservice designs and people jump on the bandwagon of pretending like criticizing microservice designs is somehow more well-rounded or more nuanced, but really it's not. It's just an attempt to make something fashionable via contrarianism.

> "I think engineers should aim to be problem solvers"

I agree with this very much and it is why I think cross-silo / cross- functional engineering is junk. The best way to organize a team of problem solvers is to clearly delineate the boundaries between what the problem solving responsibilities are.

If people use the term "problem solver" to just be an ambiguous bucket of unlimited complexity by virtue of expecting people to "just solve the problem" no matter what the impedance mismatch between their skill area and the problem area, then it renders the term "problem solver" meaningless, and will just lead to a big mess of dysfunction.

As an engineering manager, one of my most important jobs is to empower engineers to say "no." To reject inappropriately allocated work or inappropriate cross-functional pivoting driven by ineffective short term business thinking.

The engineers have to be empowered to say, "Hey, that work should not be assigned to us" because it signals whether the business overall has structured itself and staffed itself appropriately to actually respond to the business problems sent by Mother Nature at us.

If we are structured wrongly, yet try to paper over it by pressuring engineers to be HR-approved "problem solvers" in the sense of more just doing what they are told instead of doing what would actually work, it will be medium-term detrimental and counter-productive.

In this sense, I think "silo" is a good word, and indicates a good engineering culture where different silos have the power to say "no" and where specializations are respected and planned for by the management.

Yes, of course that can be subverted into an anti-pattern in poorly run businesses, but that's a property of bad management, not of "silos" in and of themselves.

<comment><USER10> > I don't buy the argument that it adds overhead. In fact I'd say it > explicitly reduces overhead

At the very least microservices add infrastructure overhead and network latency.

In terms of everyday development complexity, instead of 1 project for a monolithic application you now have n projects, one for each microservice, which is fine if your organization is large enough and sufficiently well- organised to adhere to a "One team is responsible for each microservice." organisational pattern.

If, however, your developers find themselves juggling multiple projects at a time and having to run several microservices on their local machine in order to make a change this might indicate that either there's an impedance mismatch between the communication structure of your organization and the design of your product ([https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)) or that your application simply isn't sufficiently complex yet to warrant the use of microservice patterns.

> In other words, I think good hygiene would say defaulting to microservices > is the right idea

Good hygiene is possible without microservices, too, just as microservices can be used to build the worst kind of monolith: The distributed monolith.

> If people use the term "problem solver" to just be an ambiguous bucket of > unlimited complexity by virtue of expecting people to "just solve the > problem" no matter what the impedance mismatch between their skill area and > the problem area, then it renders the term "problem solver" meaningless, and > will just lead to a big mess of dysfunction.

I suppose it depends on how an organisation manages and breaks down tasks. If for example you work on a user story level a single developer can indeed be responsible for implementing a complete story including all aspects that might be involved. "Responsible for" doesn't mean "You have to do it all by yourself.". If you have a particular problem ask a specialist and ideally everyone involved will even learn something new in the process.

When viewed from an impedance mismatch perspective the front-end / back-end distinction in some ways is quite arbitrary.

The prototypical example of impedance mismatch is the one between object- oriented programming and relational data. However, most would expect back-end developers to be both skilled in - say - Java and a relevant SQL dialect.

The impedance mismatch between a front-end technology such as Angular and a back-end technology such as Spring (both of which make use of similar patterns) is much less pronounced than that between SQL and an object-oriented language.

<comment><USER11> > "which is fine if your organization is large enough and sufficiently well- > organised to adhere to a "One team is responsible for each microservice." > organisational pattern."

I actually think the opposite is true. Having the developers on a single team manage N different service-specific projects is far simpler and lower overhead, because the infrastructure overhead of N different projects is the trivial part, compared with the complexity of managing the internal state of a single project responsible for too many things.

It's like separating a software implementation into multiple different functional units, either different classes or modules or functions, to decouple them and keep them cleanly separated for testing. The "overhead" of N different specific classes is not actually a legitimate concern compared with the overhead of a single class trying to do N overlapping things (or functional units if using a different programming paradigm). It's no different for microservices.

Plus it's fairly simple to run your own container orchestration layer that allows efficiently mapping different microservices onto heterogeneous hardware resources, whether in your own data center or with a cloud provider.

For example, my team operates different web services for different machine learning applications. One service might do nothing but predict the age of a person in a photo. Another web service might do nothing by predict the gender. From experience, I can tell you that muddying these two things together into a single web service, just because the two endpoints are separate concepts, is a bad idea. It complicates testing, the organization of acceptance test data sets, the ability to scale out the resource needs of the different models separately, to control how they are deployed. You superficially feel like you are "saving effort" on the tiny boilerplate code that is repeated between the two to expose endpoints, sanitize inputs, etc. (most of which can be factored into an internal software package anyway, to have good code reuse), but really you are not at all, because the growth of the testing code, single-project deployment and build code, etc., dwarfs whatever tiny amount of repeat web framework stuff there might have been.

They are just different logical units of concern, even if they are components of the same broader API of machine learning services we provide. I think it would represent a classic example of what you are describing as a case when you'd prefer not to organize it as microservices, and yet experience has conclusively shown my team at least that there is much greater boilerplate and mangled overhead involved with putting them into the same web service than with keeping them separate and duplicating an utterly tiny amount of work on the web service wrapper part. And this is all with the same team members maintaining and extended all of the services in a small company. It just streamlines and reduces our work to do it with microservices.

> "If, however, your developers find themselves juggling multiple projects at > a time and having to run several microservices on their local machine in > order to make a change this might indicate that either there's an impedance > mismatch between the communication structure of your organization and the > design of your product"

I actually disagree with this, and also it is an incorrect use of "Conway's Law" (which is about software organizational structure taking on the same organizational structure of the social and communication patterns of the company, and being limited to repeat those structures as the communication process limits the design). None of that affects sets of services differently whether they are bundles or separated as microservices. Conway's Law would affect the design limitation the same way in either case, and the organization as separate or coupled services would be a totally different thing, happening at a metaorganizational level to the level where Conway's law can be applicable to software.

It's also actually quite nice and easy to write extremely simple tooling with e.g. docker-compose and a trivial Makefile to control local development that has effects spanning multiple microservices. And in fact this creates really nice, version controlled artifacts that indicate how that local testing and organization works, which is often severely lacking inside the internals of a more monolithic multi-service single project, where you might be able to run it locally with superficially simpler looking commands or resources, but then the internal operation is overly coupled between services and you cannot easily see which things you can modify or change without impacting other things in unintended ways.

Lastly, I think you missed the point of my comment on impedance mismatch. The problem would be taking someone who is a specialized engineer in X but then expecting them to "be a problem solver" by spending time on Y, where the person's value add is huge if you let them work on X, but is tiny if you ask them to work on Y, even after accounting for whether the business needs X or Y at the moment.

For example, taking one of your best front-end engineers and requiring them to fix some broken database normalization problem, or write a stored procedure, instead of having pre-arranged for the team to contain the necessary expertise such that the front-end person can delegate that task to someone whose comparative value add is all on the data engineering side, meanwhile the front-end person goes back to work on more front-end tasks, where their comparative value add is high.

The impedance mismatch comes from recognizing that if you keep a specialist in X busy with work in X, it is more optimal for the company (and more morale building for the worker), than if you ask them to be preemptible to stop doing X and instead do Y or Z which ostensibly should be things farmed out to specialists in Y or Z.

It can be this way with a backend engineer, a front-end engineer, a scientific computing expert, a database expert, whatever.

You are taking the classic impedance mismatch example of an ORM too literally, because the general idea is that you are restricting the valuable flow of something (the specialized skill of the worker) instead of fundamentally reorganizing resources so as to not need to restrict it (by cleanly separating responsibilities into different silos of specialization).

</comment></comment></comment></comment></comment></comment><comment><USER12> This is why category theory interests developers. Composing programs like lego bricks.

It is more nuanced that, distros involve a lot of snowflake programs using several build systems using several languages many of which do not compose well together.

The ecosystem is gravitating back into a homogeneous LLVM back end reminiscent of COBOL/C/FORTRAN all playing well together.

Build systems are still a mess. Cmake and Bazel for now are on top. The next winner will allow for massively distributed builds on AWS Lambda and S3. I'm personally working on a distro for AWS Lambda.

<comment><USER13> Bazel's buildfarm remote execution service is growing: [https://github.com/bazelbuild/bazel- buildfarm](https://github.com/bazelbuild/bazel-buildfarm)

</comment></comment><comment><USER14> Red Hat (and I imagine Fedora) has a concept a little like this: when installing the system, you can select from a list of "roles", and those roles in turn imply a bunch of individual packages.

But, there's not many of them, and from memory, there's really only "Desktop" and "Developer Workstation" as options like the sort you're proposing.

<comment><USER15> Redhat/Fedora groups are broken up a lot more than that. From a RHEL 7.5 box:

      # yum grouplist
      Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
      There is no installed groups file.
      Maybe run: yum groups mark convert (see man yum)
      Available Environment Groups:
         Minimal Install
         Infrastructure Server
         File and Print Server
         Basic Web Server
         Virtualization Host
         Server with GUI
      Available Groups:
         Compatibility Libraries
         Console Internet Tools
         Development Tools
         Graphical Administration Tools
         Legacy UNIX Compatibility
         Scientific Support
         Security Tools
         Smart Card Support
         System Administration Tools
         System Management

You can install any of these later, eg.

       yum groupinstall "Development Tools"

<comment><USER14> So of those, perhaps "Development Tools", "Scientific Support", and perhaps a couple of others reflect the OP's proposal of high-level task-centric modular functionality.

But there's no reason that groups couldn't be configured for "Musician's Tools", "Artist's Tools", "Educator's Tools", etc.

<comment><USER15> The arbitrary groups would need to have a comps.xml file generated.

[https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml...](https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups)

You can pass these to createrepo with the -g flag to create/update package groups in an YUM/DNF repository.

</comment></comment></comment></comment><comment><USER16> Shared, assembleable components is a dream shared by good projects such as Node-RED and the Sugar desktop environment.

There's a lot of rethinking what an app is that's necessary to get to a more "lego" like system, where things snap together & work together via common, regular interfaces. It requires throwing out a colossal amount of the user- experience work we've done, & finding broad top-down principles & systems that serve and guide & place & route the individual components & their connections, which is "some seriously next level shit".

[https://nodered.org/](https://nodered.org/)

[https://wiki.sugarlabs.org/go/Getting_Started](https://wiki.sugarlabs.org/go/Getting_Started)

</comment><comment><USER17> Reminds me of "Software ICs" and the Brad Cox book "Object-Oriented Programming: An Evolutionary Approach", 1991 if not before (I'm seeing the 2nd edition). He co-created Objective-C.

</comment><comment><AUTHOR> Missing from top:

These Days there is a new project for an already existing project on the same topic which is in a Way fragmenting the Market more and more - Yes Different features etc etc. but why not work on a common problem - Extend the functionality and allow the user to chose the things he needs - You buy a lego set and you can mix and match with a set from 10 years ago

Is it because everyone wants to lead a project, opinions differ on the solution approach or something else

<comment><USER8> You nailed it with the last line: people. Everyone wants to rule the world. This fundamentally doesn't work, but that fact doesn't stop everyone from irrationally trying anyway.

The problem you are getting at is entirely sociopolitical, and is, sadly, effectively unsolveable. I spent a decade and a half figuring this out (started circa 2003, gave up roughly last year). It was a good journey.

If I was going to pick a starting point to springboard off of, it would be that humans are embarassingly easy to social-engineer. With developers, you just stroke their egos a bit, make them feel validated and secure, and they'll build pretty much whatever you want. Managers have the opportunity to exert power and control over _entire teams of people!!1_ and this is so fun to play with sometimes the end goal (the enabler of the control, aka the responsibility) nearly (or actually :/) goes out the window.

It only takes a little bit of study to reverse-engineer the brain and almost immediately you'll get actionable insights on how to make people feel like they're getting what they really want when you're actually making them achieve your agenda instead. Fill people's heads/lives with movement they have to keep up with, make it so they can ride it like a fun wave if they do it right, and bam, you can control lots of people.

Crowd dynamics is so fascinating.

I'm not even touching on office politics, cults, etc.

Sadly open source has its own toxicities. Linux is in many ways the PHP of operating systems; some really amazing bits hiding away in invisible corners, but no good oversight due to its bazaar-based design, and thus no cohesiveness. You will never get very far trying to push balanced views within Linux; the community has become too much of a reactive-yet-immobilized culture. The Lennart Poettering debacle is one recent example.

Moving away from open source specifically, software design itself is also fundamentally broken because it tries to abstract out the people - what put the _intelligence_ into "artificial intelligence"! - as perfect infallible beings that _sometimes_ make mistakes. (For example, why on earth do programming languages describe errors as "exceptions"?!)

Programming is full of leaky abstractions that have never been properly followed up on and properly ironed out of the woodwork.

What we're currently stuck with is are systems that are intrinsically tied to individuals' mindset and skills, and as a result no two codebases are really the same.

So, it's generally really impressive if you can take Random Component A and expect it to work properly with Random Component B. One example I can pull of the top of my head right now: [https://github.com/taviso/loadlibrary](https://github.com/taviso/loadlibrary)

Another way to describe this would be to say that "taking anything and making it work with anything else" is Very™ Very® _ʎɹǝΛ_ NP-Hard™©®, if not categorically impossible. (This is what took me 15+ years to accept.)

In terms of perfect governance, I definitely take a cyberpunk stance. [https://news.ycombinator.com/item?id=17320295](https://news.ycombinator.com/item?id=17320295) [https://news.ycombinator.com/item?id=17083221](https://news.ycombinator.com/item?id=17083221)

I also just found this and am adding it in: [https://news.ycombinator.com/item?id=17322457](https://news.ycombinator.com/item?id=17322457)

Related thoughts/continuation: [https://news.ycombinator.com/item?id=17299517](https://news.ycombinator.com/item?id=17299517) (if you're truly interested, you might follow all the continuation links)

TL;DR study people, bureaucracy and sociopolitical crowd dynamics

<comment><AUTHOR> Thanks for this, ill take a look :)

</comment></comment></comment><comment><USER8> I took another look at your post, and figured a 2nd comment would be best.

What would be the value of separating users into isolated groups? What if I want to belong to multiple groups? The simple ideology you've used breaks down.

Okay, so you could add extra subgroups, but here's the thing - this sort of thing gets tried all the time, the abstractions inevitably break, the implementer(s) give up (hopefully after not too much time invested).

The TL;DR of this mindset is that _complexity is sometimes good_. Sometimes the right tool for the job is the most complex tool, which exposes all the features and shows you the 9,999 knobs and switches and buttons at once. Lot to take in, but then you can do whatever you want.

Trying to shoehorn complexity into Fisher-Price user interfaces results in hamstrung yet bloated systems with more complexity than will ever be used. That's what happened with Electron, incidentally, and why some feel so uncomfortable and have such cognitive dissonance about it, I think.

<comment><AUTHOR> I like the part in Photoshop, Where you could say for what you wish to use it and it would rearrange the menus or add and remove certain options which are needed for that Use case, this and some other cases influenced my question,

Do you think it is a waste of resources having so many tools which do so many things the same way + a few unique options,

I like the ShareX tool (screen recording) which asks me to install the extra feature if i wish to use Screen recording, (goes back to the previous comenter who mentioned it is basically packages)

I hope i am making myself clear in the questions and comments :D , not a native eng speaker and also didnt really prepare the question well, it just came to me in a rush as it was stuck in my head for a long time, sorry about that,

Sometimes i look at old software and some new one (sublime text) where devs worked hard for our resources where as today, (luckily i have 16 GB) there seems to be a lack for performance or the will to design efficient systems (due to abundance of resources in PCs?)

What did you mean isolating users into groups? I wouldnt want that :D, but i mentioned it as a layer on top of Core things, example

All users want video and web tech - but then some are more specific - <USER3> specifics would be the packages they get bundled on top of core features, and the Collective groups of devs work on those

Linux drivers and installing certain software is sometimes a real pain and can vary from distro to distro , if the linux is to succeed shouldnt we collectively fight to avoid this barrier

Forgive me folks its my first time doing this i think i jump here and there ;D perhaps even confusing you sometimes...

I will update the email Thanks

<comment><USER8> Quote-replying is probably a good idea

(For once regex find and replace in my editor worked!)

> _I like the part in Photoshop, Where you could say for what you wish to use > it and it would rearrange the menus or add and remove certain options which > are needed for that Use case, this and some other cases influenced my > question,_

That's nice UX design, I agree. It certainly increases the Q&A workload though.

> _Do you think it is a waste of resources having so many tools which do so > many things the same way + a few unique options,_

Most definitely, but we're stuck with no alternatives at this point.

> _I like the ShareX tool (screen recording) which asks me to install the > extra feature if i wish to use Screen recording, (goes back to the previous > comenter who mentioned it is basically packages)_

This is a wise approach. The problem is that it requires additional testing load than if everything were installed by default.

> _I hope i am making myself clear in the questions and comments :D_

You're fine.

> _not a native eng speaker_

But easily understandable :)

> _and also didnt really prepare the question well_

You've held together very well.

> _it just came to me in a rush as it was stuck in my head for a long time, > sorry about that,_

It's fine. Really.

> _Sometimes i look at old software and some new one (sublime text) where devs > worked hard for our resources where as today, (luckily i have 16 GB) there > seems to be a lack for performance or the will to design efficient systems > (due to abundance of resources in PCs?)_

I do this every day running Chrome on a 12-year old single-core 32-bit laptop with 2GB RAM :D everything's _constantly_ swapping like crazy. Sometimes a single tab will take 10 seconds to open. New URLs routinely take half a minute or more for the webpage to display. It's fun, and a lesson in... something, I'm not sure what, but I'm definitely learning it inside and out.

I think it's all about the vague threshold that management can't get away with shipping a product because it's so horrible that users will simply outright reject it. Software bloats out to the point where it sits just above that unusability threshold, then it hovers there. I think this is the rule that governs everything.

Enterprise systems are at the worst end of this; they're frequently so horribly slow they're unbearable. This is because they are used by a captive audience that cannot switch away even if they want to.

Pretty much everything else "settles" after a while so it sits just above this threshold.

What with the progression of tech, this means that if you install Word 97 in a Win95/98 VM (or maybe it'll even work natively :D), you'll notice that it only uses 8MB RAM, and then when you minimize the window it suddenly collapses down to 4MB! Or, for another example, the cross-platform old KDX filesharing client uses all of 8MB RAM on Linux. Never seen another app like it. I think the reason this is depressing is because when we run out of RAM we get sad, and then we think of how amazing things _could_ be... but in real life it doesn't work that way, when we build applications we take advantage of the resources that are available.

> _What did you mean isolating users into groups? I wouldnt want that :D, but > i mentioned it as a layer on top of Core things, example_

> _All users want video and web tech - but then some are more specific - <USER3> > specifics would be the packages they get bundled on top of core features, > and the Collective groups of devs work on those_

OK, I meant this bit in your post:

> _Imagine Having a Single distro which once you install the Core on your > Computer asks you Which group you belong?_

> _-Musician -Scientist -Education -Artist - Developer etc._

These are very vague titles, and their meaning is not very unambiguously defined. I could interpret them in many different ways. This is where the leaky abstractions start.

Using your groupings:

\- If I'm a game developer, I might be a musician, artist and developer.

\- If I'm a teacher, I might pick education and scientist.

You said "which group [do] you belong [to]?", with group being singular not plural. This is where I was getting isolation from.

Okay, sure, so you make it so people can be in multiple groups. But then you loose the optimal efficiency you're chasing; if I'm a game developer I might want specific art tools installed, and installing _all_ the art tools might be a waste. So, okay, say you break the categories down, and add "game developer"... but then the 500 different kinds of game developers will all have something to say, and this is where things get really messy. :)

To rephrase my earlier comment, providing the complexity and not isolating it has worked out to be the best practical solution.

In order for grouping to be successful, it would need to be _better_ , and provide _more flexibility_ than simply throwing everything in everyone's face. So the grouping mechanism needs to hold up to the kinds of edge cases I've described.

> _Linux drivers and installing certain software is sometimes a real pain and > can vary from distro to distro , if the linux is to succeed shouldnt we > collectively fight to avoid this barrier_

Consider that 100 and probably 1000 people before you have tried to figure this out. As I said, I gave the same considerations 16 years :) so surely others have thought long about this as well.

Ultimately the solution there is to simply learn the various systems.

> _Forgive me folks its my first time doing this i think i jump here and there > ;D perhaps even confusing you sometimes..._

Nope, it's fine, I can follow along.

I have a slightly tangential thought to add at this point.

The reason I personally went down the specific paths I did with trying to understand the way things were and the rationale behind everything, was as a coping/reaction mechanism for my ADHD. I had a hard time trying to grapple with the seemingly infinite complexity I was being presented with (with Linux, open source, software development, etc), and I tried various techniques to try and make sense of everything in spite of not being able to grasp the bigger picture.

Naturally, this noble endeavor was itself also compromised due to the ADHD. I couldn't even workaround my ADHD effectively, because of my ADHD. Sigh. Turtles all the way down.

I've found that alternative therapies can be unbelievably effective for mental health, so I've made some good strides with comprehension in recent years.

You mention jumping around a bit, that you decided to talk about this in a rush, etc. I used to be like that :) (let me see if I'm right: you posted this in a rush before you overthought about it or got bored?) so I'll mention something I realized that was specifically helpful from an ADHD standpoint.

First of all, when I started poking Linux I wanted to find "the one true Linux, the most authentic experience". It took me years to understand why I even wanted this in the first place and why it seemed so necessary.

It had to do with how I learned: I couldn't just throw a bunch of information in my head and have it arrange itself; the attention span necessary for that to function wasn't available. I needed to handhold the organizational process a bit more, and to do that I needed to explicitly find and tag foundational aspects of what I was learning about so I could keep those in mind as I stumbled on new information and figured out what to associate it with.

Problem was, I couldn't figure out what to classify as foundational. Where was "the root"?

Here's an answer that took me 10 years to realize: Linux is a relativist system, not an absolute system. Or, in more contemporary parlance (as noted by another comment in this thread), it's bottom-up, not top-down. So everything is relative. There _are_ no roots.

The best way to properly understand "Linux" is to simply just dive in _somewhere_ but focus on absorbing as much history as you can; each historical bit of info will help you make more sense of things.

> _I will update the email Thanks_

Cool!

FWIW, I must say upfront that I'm TERRIBLE at frequent back and forth communication. I tend to use email as a once-every-6-months ping mechanism. If I say hi any more frequently than that, miracles are happening :)

So, don't be surprised if I take ages to reply. I burn out easily (still working on fixing this).

</comment></comment></comment><comment><USER18> This is a really cool idea. It would be great to have something like this but for react. The barrier there seems to be that everyone would have to adopt a common compenetized css standard.

</comment><comment><USER19> [https://en.wikipedia.org/wiki/Smalltalk](https://en.wikipedia.org/wiki/Smalltalk)

</comment><comment><USER20> If you compare a Lego toy with a molded one you'll see that the Lego toy easily breaks apart, isn't as polished and depends many parts.

This is all things we don't like in the software world.

</comment><comment><USER21> The solution is the semantic web.

<comment><AUTHOR> You went All in On Web :D, what about other Systems and Tools, thanks

</comment></comment><comment><USER22> Sound engineers have tried this many times....

<comment><AUTHOR> Any Reading you recommend or sources, or just saying Thanks</comment></comment>