|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
Wikipedia defines this term as (Continuous delivery - Wikipedia)
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.
The idea of continuous delivery comes as a generalization of the idea of nightly builds that are common practice in many software companies. The new twist is higher level of automaton of acceptance testing using battery of tests that are applied to each build. The idea pioneered by Perl many decades ago. Ideally developers approve or initiate the deployment, and all testing is dome by some robotic machinery. If successful the release goes into production. The positive idea here is the level of automation of acceptance testing for most applications can be dramatically increased. Often using existing, off the shelf testing tools and packages that do not cost all that much in companion with the cost of human labor. So this is variation of the theme "robots eat people".
Highly sophisticated and highly automated acceptance testing is performed for compliers and interpreters for a long time. Probably decades, if we are talking about, for example Perl interpreter. Here how enthusiasts of this approach try to sell it ( The quickie guide to continuous delivery in DevOps )
To start with, the terms apply to different parts of the same production arc, each of which are automated to different degrees:
- Continuous integration means frequently merging code into a central repository. "Frequently" means usually several times a day. Each merge triggers an automated "build and test" instance, a process sometimes called continuous build . But by either name, continuous integration and continuous build do nothing in terms of delivery or deployment. They're about code management, not what happens to the code afterward.
- Continuous delivery refers to the automation of the software release process, which includes some hands-on effort by developers. Usually, developers approve or initiate the deployment, though there can be other manual steps as well.
- Continuous deployment is continuous delivery with no manual steps for developers. The whole thing is automated, and it requires not so much as a nod from humans.
With continuous deployment, "a developer's job typically ends at reviewing a pull request from a teammate and merging it to the master branch," explains Marko Anastasov in a blog post .
But when the result of such "robotically tested builds" are pushed into production, huge unanticipated problems might arise, when you can't define algorithmically all most typical scenarios. Murphy law guarantees that. In other words automated testing can't fully replace trained testers and pilot users and weeks of month of their experience with the new release.
It still makes sense for a very small teams, and very specific software domains. Actually it favors "a single isolated developer" (lone wolf) approach. But at the same time it gives developer too much freedom which they naturally tend to abuse. Too much rope to hang themselves. The risks of malfunction of newly baked code are high, no matter how much automated testing was performed, unless the change is trivial (and even in this case there might be problems, Year 2000 scare is one example here).
Continues delivery often is practiced by developers of small Web sites or utilities (when the current release is always the current build from, for example, gitube). And even for those small scale projects, the users sometimes are badly burned. In other words this approach does not scale up outside of small applications such as utilities, web site scripts, and few other specific software domains. Especially, if the user interaction with application is complex. Simple, primitive Web interfaces like used by Netflix are more amendable to this approach. If you go up in complexity things became much less rosy.
In a way, this is return on a new level of pipe dream of verification enthusiasts: that there is a magic bullet that allow you to produce bug free software using some formal or semi-formal methods. This time automated testing is the magic bullet. But as a general statement this is clearly an attempt to sell a snake oil and people who are doing it are clearly charlatans. There is no magic bullet.
Yeah, maybe there's something useful in continues delivery in small software projects with very few users, which are run highly disciplined and talented developers, but as you go up in complexity and size of the user population, risks became way too high to try it. Nothing alienates customers more then being a guinea pigs for developers.
|
Nothing alienates customers more then being a guinea pigs for developers. |
Another great suspicion comes from the fact that the articles advocating continued delivery typically are devoid of any substance. One of the most difficult problem is creating the new release is how to avoid "software featurism" and not to lose a part of conceptual integrity of the product. continues delivery removes some barriers for developers. And those developers who were added to the project at the late stage do not understand the underling philosophy and underling compromises by their enthusiasm can destroy perfectly viable product.
Another waning sign for "continues delivery" hoopla is that most articles that cover this topic are just buzzword soup with a dash of spicy new technologies names like DevOps thrown in. Five years ago they would have said practically the same words, but just talked about another fashionable technology instead. This type of content is called techno scam and people who produce it techno scamsters. That doesn't mean that continues delivery is complete sham, but as project size of complexity grows it became one very soon indeed.
But the message of people who beat the drum and match with this banner is that all you need is to switch. And everything is better. Yeah, right ;-)
When they are talking about higher customer satisfaction this is another scam. Of cause, if you set the level of customer satisfaction low enough (for example, if you settle for the level at which customers do not beat the developers as high customer satisfaction ;-) you are fine. But in reality most such companies have abysmal customer satisfaction ratings because continuous delivery is equal to constant change and customers do not like it. Constant change might be not so bad for developers, they used to live in this world, and typically they are not afraid of braking compatibility if it bring substantial benefits. But constantly changing product is "Alice in wonderland" reenacted on a new technological level. It is a nightmare for the poor customers of such product.
Any professional software developer will test a new software release thoroughly before letting it get anywhere close to an production environment, especially where their business is at stake. So the fact the most efforts of professional software developers are shifted from pure development to testing is not an aberration. This is a requirements for achieving high quality, because this activity that allow developers to feel the total complexity of the product and how the part designed by him/her actually interacts with other parts. Complexity slows everything down. That's why productivity of professional developers is so low, costs are so high and project schedule overruns are typical.
and that's why software typically has rather rare releases and even more rare versions upgrades. They are milestone for fully tested product releases that achieved some level of conceptual integrity (with most reckless contributions and ideas discarded), and that should not cause major problem downstream, when deployed. the only activity when something more or less resembling continues delivery paradigm can be found for large software project is security patching. And believe me just a dose of programs few thousand lines each is enough to lose understanding of what is what for even talented developers. At this point they are simply afraid to touch the code. There are exceptions to this rule, and some developers do not slow as much with the increasing complexity of the codebase, but they are rare.
Depending on complexity, the scope of the changes, the level of bureaucracy and qualification of the workforce the process of creating viable new release of a software product can take anywhere from a week or two to several months, or even a year. New versions (major releases of a software product that add/remove important features) for mature product usually take more then a year. This time is less for new products, but is rarely less then six month. You can look at Linux kernel release history to see the tendency here.
Timing also depends on the severity bugs found and fixed in previous release, and whether any alterations to the internals, or interface, or working practices have to be introduced.
So to have developers lob a new "release" over the wall at frequent intervals is not useful, it isn't clever, and does not save any money, or speed up the development. It just create a mess, a real nightmare for everybody involved. Except political hacks who usually push for it -- when things became hot people often discover that those slick guys who can do wonderful presentations already jumped to greener pastures (often still on mission to destroy another company, or product ;-) and there is nobody to fire for the mess created.
In essence, continues delivery offloads the most difficult arts of testing to the users, floods the change control process and helpdesk with "issues" that should be ironed out before the release, and thus dramatically increases the level of stress. If releases are way too frequent and ticket processing is slow you encounter a paradoxical situation when the problem reported for the release, that is no longer deployed. In this case, and if major customers are forced to report the same bugs for several consequent releases, you can be sure that they will jump the ship very soon. You might even get the angry letter with the threat to do so :-)
Any professional software development team can't rely only of automatic testing for a new release of more or less complex product (it does not matter, whether this is in-house or commercial product). Users need to be involved, or at least professional testers who imitate users. Letting it get anywhere close to an environment where their business is at stake is suicidal. Just imagine if continues delivery is applied to production of pacemaker software.
There is a claim that continues delivery helps developers to concentrated of development instead of the bureaucratic maze connected with testing, deployment and support. To a certain extent this is true, but the price can be way to high. You can fight the situation when developers are more focused upon deployment/testing then actual development with other means. for example by hiring additional testers. One to one ration of developers and testers might be more optimal then many think.
Without strict version control and scheduled dates of release the developers just push too many things out and production support is responsible for addressing the resulting mess. It is not only horrible stupid practice, but it created disconnect and alienation between developers and other personnel down the food chain. So it is one thing when in very small problem a small group of developers is responsible for everything. They can practice "continues delivery" within the certain bounds and level of discipline. But if testing and production are separate organization units forget about it: the level of disconnect between developers and other departments will create consistent outages. So the only slight chance to succeed is to adopt the mantra developers should "Eat your own dog food", and support the crap they push. This is a very expensive proposition, even for small projects. Actually for anything larger that a non-profit website.
The crux of the problem is that we (in these discussions and the analysts) describe *all* types of software development are the same. They are not. there is a difference between developing a small desktop application, an embedded microcontroller in industrial equipment, a web application for people to get work done, or a webapp to let people see the latest funny cat video. I would be terrified if 'continuous delivery' is adopted for a software in the microcontroller of a health care device.
another way to view continuous delivery is as an attempt to automate the decision-making process that decide when a new release is deployed. In this case supposedly you deploy some sophisticated automated testing process that automatically (or with a click of a button) determine whether all test criteria are met. If this particular release passed all the tests it can be deployed. This is probably possible for development of compilers and scripting language interpreters like Perl interpreter (that is know for vast library of test cases), but generally this is a pipe dream, because with the change of software typically acceptance criteria typically also slightly change.
In any case continues delivery is not a good thing for those poor customers who were chosen to be
involuntary beta testers as well as for the rest of the customers who have to deal with software that
is constantly changing. Roll back in case "continues delivery" produced a batched result often
is not enough. It is too little too late. Note that a customer with a choice is likely to just go somewhere
else rather than use your software. Like one Slashdot read wrote "All I know is that, as
a user, rapid-release or continuous delivery has been nothing but an enormous pain in the ass to me
and I wish it would die the horrible death it deserves already."
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
While it's easy to start up a few, flashy new DevOps teams, releasing to production each week and flaunting the ball-and-chain of enterprise governance, scaling that change to your organisation will always be challenging, if not crushingly impossible. When it comes to scaling the skunk-works, I'm reminded of a conversation …
|
|
|
Aug 29, 2017 | insights.hpe.com
The quickie guide to continuous delivery in DevOpsIn today's world, you have to develop and deliver almost in the same breath. Here's a quick guide to help you figure out which continuous delivery concepts will help you breathe easy, and which are only hot air. Developers are always under pressure to produce more and release software faster, which encourages the adoption of new concepts and tools. But confusing buzzwords obfuscate real technology and business benefits, particularly when a vendor has something to sell. That makes it hard to determine what works best -- for real, not just as a marketing phrase -- in the continuous flow of build and deliver processes. This article gives you the basics of continuous delivery to help you sort it all out.
To start with, the terms apply to different parts of the same production arc, each of which are automated to different degrees:
- Continuous integration means frequently merging code into a central repository . "Frequently" means usually several times a day. Each merge triggers an automated "build and test" instance, a process sometimes called continuous build . But by either name, continuous integration and continuous build do nothing in terms of delivery or deployment. They're about code management, not what happens to the code afterward.
- Continuous delivery refers to the automation of the software release process , which includes some hands-on effort by developers. Usually, developers approve or initiate the deployment, though there can be other manual steps as well.
- Continuous deployment is continuous delivery with no manual steps for developers. The whole thing is automated, and it requires not so much as a nod from humans.
With continuous deployment, "a developer's job typically ends at reviewing a pull request from a teammate and merging it to the master branch," explains Marko Anastasov in a blog post . "A continuous integration/continuous deployment service takes over from there by running all tests and deploying the code to production, while keeping the team informed about [the] outcome of every important event."
However, knowing the terms and their definitions isn't enough to help you determine when and where it is best to use each. Because, of course, every shop is different.
It would be great if the market clearly distinguished between concepts and tools and their uses, as they do with terms like DevOps. Oh, wait.
"DevOps is a concept, an idea, a life philosophy," says Gottfried Sehringer, chief marketing officer at XebiaLabs , a software delivery automation company. "It's not really a process or a toolset, or a technology."
But, alas, industry terms are rarely spelled out that succinctly. Nor are they followed with hints and tips on how and when to use them. Hence this guide, which aims to help you learn when to use what.
Choose your accelerator according to your need for speedBut wait -- Isn't speed the key to all software development? These days, companies routinely require their developers to update or add features once per day, week, or month. This was unheard of back in the day, even in the era of agile software development .
That's not the end of it; some businesses push for software updates to be faster still. "If you work for Amazon, it might be every few seconds," says Sehringer.
Even if you're a deity of software bug-squashing, how can you -- or any developer or operations specialist -- deliver high-quality, "don't break anything" code when you have to build and release that fast? Everyone has their own magic bullet. "Agile -- " cries one crowd. " Continuous build -- " yells another. " Continuous integration -- " cheers a third.
Let's just cut to the chase on all that, shall we?
"Just think of continuous as 'automated,'" says Nate Berent-Spillson, senior delivery director at Nexient , a software services provider. "Automation is driving down cost and the time to develop and deploy."
Well, frack, why don't people just say automation?
Add to the idea of automation the concepts of continuous build, continuous delivery, continuous everything, which are central to DevOps, and we find ourselves talking in circles. So, let's get right to sorting all that out.
... ... ...
Rinse. Repeat, repeat, repeat, repeat (the point of automation in DevOps)Automation has obvious returns on investment. "You can make sure it's good in pre-production and push it immediately to production without breaking anything, and then just repeat, repeat, repeat, over and over again," says Sehringer.
In other words, you move delivery through all the steps in a structured, repeatable, automated way to reduce risk and increase the speed of releases and updates.
In an ideal world, you would push a button to release every few seconds," Sehringer says. But this is not an ideal world, and so people plug up the process along the way.
A company may need approval for an application change from its legal department. "Some companies are heavily regulated and may need additional gates to ensure compliance," notes Sehringer. "It's important to understand where these bottlenecks are." The ARA software should improve efficiencies and ensure the application is released or updated on schedule.
"Developers are more familiar with continuous integration," he says. "Application release automation is more recent and thus less understood."
... ... ...
Pam Baker has written hundreds of articles published in leading technology, business and finance publications including InformationWeek, Institutional Investor magazine, CIO.com, NetworkWorld, ComputerWorld, IT World, Linux World, and more. She has also authored several analytical studies on technology, eight books -- the latest of which is Data Divination: Big Data Strategies -- and an award-winning documentary on paper-making. She is a member of the National Press Club, Society of Professional Journalists and the Internet Press Guild.
|
|
|
Aug 28, 2017 | developers.slashdot.org
Anonymous Coward writes:
xbytor ( 215790 ) , Sunday August 27, 2017 @04:00PM ( #55093989 ) HomepageYeah, this is an incredibly low quality article. It doesn't specify what it means by what AI should do, doesn't specify which type of AI, doesn't specify why AI should be used, etc. Junk article.
It's basically a bullshit bingo post where someone repeats a buzzword without any knowledge of the material behind it.
buzzwords Score: , Funny)cyber-vandal ( 148830 ) writes:> a new paradigm shift.
I stopped reading after this.
Re: buzzwordssycodon ( 149926 ) , Sunday August 27, 2017 @04:10PM ( #55094039 )Not enough leveraging core competencies through blue sky thinking and synergistic best of breed cloud machine learning for you?
Same Old Thing Score: , Insightful)AmazingRuss ( 555076 ) writes:Holy Fuck.
Continuous integration Prototyping Incremental development Rapid application development Agile development Waterfall development Spiral development
Now, introducing, "Continuous Delivery"...or something.
Here is the actual model, a model that will exist for the next 1,000 years.
1. Someone (or something) gathers requirement. 2. They get it wrong. 3. They develop the wrong thing that doesn't even work they way they thought it should 4. The project leader is canned 5. The software is implemented by an outside vendor, with all the flaws. 6. The software operates finally after 5 years of modifications to both the software and the workflows (to match the flaws in the software). 7. As soon as it's all running properly and everyone is trained, a new project is launched to redo it, "the right way". 8. Goto 1
Re:ColdWetDog ( 752185 ) writes:If everyone is stupid, no one is.
Re:Graydyn Young ( 2835695 ) writes:No no. We got rid of line numbers a long time ago.
Re:Tablizer ( 95088 ) writes:+1 Depressing
AI meets Hunger GamesTheStickBoy ( 246518 ) writes:It's a genetic algorithm where YOU are the population being flushed out each cycle.
Re:alvinrod ( 889928 ) , Sunday August 27, 2017 @04:15PM ( #55094063 )Here is the actual model, a model that will exist for the next 1,000 years.1. Someone (or something) gathers requirement. 2. They get it wrong. 3. They develop the wrong thing that doesn't even work they way they thought it should 4. The project leader is canned 5. The software is implemented by an outside vendor, with all the flaws. 6. The software operates finally after 5 years of modifications to both the software and the workflows (to match the flaws in the software). 7. As soon as it's all running properly and everyone is trained, a new project is launched to redo it, "the right way". 8. Goto 1
You just accurately described a 6 year project within our organization....and it made me cry Does this model have a name? an urban dictionary name? if not it needs one.
Re:buzzwords Score: , Insightful)phantomfive ( 622387 ) writes:Yeah, maybe there's something useful in TFA, but I'm not really inclined to go looking based on what was in the summary. At no point, did the person being quoted actually say anything of substance.
It's just buzzword soup with a dash of new technologies thrown in.
Five years ago they would have said practically the same words, but just talked about utilizing the cloud instead of AI.
I'm also a little skeptical of any study published by a company looking to sell you what the study has just claimed to be great. That doesn't mean its a complete sham, but how hard did they look for other explanations why some companies are more successful than others?
Re:Anonymous Coward writes:At first I was skeptical, but I read some online reviews of it, and it looks pretty good [slashdot.org]. All you need is some AI and everything is better.
I smell Bullshit Bingo...93 Escort Wagon ( 326346 ) writes:that's all, folks...
Meeting goalspetes_PoV ( 912422 ) , Sunday August 27, 2017 @05:56PM ( #55094339 )I notice the targets are all set from the company's point of view... including customer satisfaction. However it's quite easy to meet any goal, as long as you set it low enough.
Companies like Comcast or Qwest objectively have abysmal customer satisfaction ratings; but they likely meet their internal goal for that metric. I notice, in their public communications, they always use phrasing along the lines of "giving you an even better customer service experience" - again, the trick is to set the target low and
continuous delivery == constant change ( Score: , Insightful)SethJohnson ( 112166 ) writes:This might be good for developers, but it's a nightmare for the poor, bloody, customers.
Any professional outfit will test a new release (in-house or commercial product) thoroughly before letting it get anywhere close to an environment where their business is at stake.
This process can take anywhere from a day or two to several months, depending on the complexity of the operation, the scope of the changes, HOW MANY (developers note: not if any ) bugs are found and whether any alterations to working practices have to be introduced.
So to have developers lob a new "release" over the wall at frequent intervals is not useful, it isn't clever, nor does it save (the users) any money or speed up their acceptance. It just costs more in integration testing, floods the change control process with "issues" and means that when you report (again, developers: not if ) problems, it is virtually impossible to describe exactly which release you are referring to and even more impossible for whoever fixes the bugs to produce the same version to fix and then incorporate those fixes into whatever happens to be the latest version - that hour. Even more so when dozens of major corporate customers are ALL reporting bugs with each new version they test.
Re:Herkum01 ( 592704 ) writes:Any professional outfit will test a new release (in-house or commercial product) thoroughly before letting it get anywhere close to an environment where their business is at stake. This process can take anywhere from a day or two to several months, depending on the complexity of the operation, the scope of the changes, HOW MANY (developers note: not if any) bugs are found and whether any alterations to working practices have to be introduced.
I wanted to chime in with a tangible anecdote to support your
Re:JohnFen ( 1641097 ) writes:I can sympathize with that few, of it appearing to have too many developers focused upon deployment/testing then actual development.
However, I come at it from the other side, the developers just push new development out and production support is responsible for addressing the mess, it is horrible, there is too much disconnect between developers and their resulting output creating consistent outages. The most successful teams follow the mantra "Eat your own dog food" , developers who support the crap they push
Re:AmazingRuss ( 555076 ) writes:This might be good for developersIt's not even good for developers.
"a new paradigm shift."sethstorm ( 512897 ) writes:Another one?
Let's hope not.bobm ( 53783 ) writes:AI is enough of a problem, why make it worse?
According to one studyangel'o'sphere ( 80593 ) writes:One study, well then I'm sold.
But do you know who likes Continuous Delivery? Not the users. The users hate stuff changing for the sake of change, but trying to convince management seems an impossible task.
Re:Junta ( 36770 ) writes:Why should users not like it? If you shop on amazon you don't know if a specific feature you notice today came there via continuous delivery or a more traditional process.
Re:angel'o'sphere ( 80593 ) writes:The crux of the problem is that we (in these discussions and the analysts) describe *all* manner of 'software development' as the same thing. Whether it's a desktop application, an embedded microcontroller in industrial equipment, a web application for people to get work done, or a webapp to let people see the latest funny cat video.
Then we start talking past each other, some of us terrified what 'continious delivery' means in the context of software in the microcontroller of a health care device, others t
Re:JohnFen ( 1641097 ) writes:Well, 'continuous delievery' is a term with a defined meaning. And releasing phone apps with unwanted UI/functionality in rapid succession is not part of that definition. Continuous delievery basically only is the next logical step after continuous integration. You deploy the new functionallity automatically (or with a click of a button) when certain test criteria are met. Usually on a subset of your nodes so only a subset of your customers sees it. If you have crashes on those nodes or customer complaints you
Re:Junta ( 36770 ) writes:You deploy the new functionallity automatically (or with a click of a button) when certain test criteria are met. Usually on a subset of your nodes so only a subset of your customers sees it. If you have crashes on those nodes or customer complaints you roll back.Why do you consider this to be a good thing? It's certainly not for those poor customers who were chosen to be involuntary beta testers, and it's also not for the rest of the customers who have to deal with software that is constantly changing underneath them.
Re:manu0601 ( 2221348 ) writes:'continuous delievery' is a term with a defined meaning. And releasing phone apps with unwanted UI/functionality in rapid succession is not part of that definition.It is a natural consequence of a continuous delivery, emphasis on always evolving and changing and that the developer is king and no one can question developer opinion. Developer decides it should move, it moves. No pesky human testers to stand up and say 'you confused the piss out of us' to make them rethink it. No automatic test is going to capture 'confuse the piss out of the poor non-developer users'.
If you have crashes on those nodes or customer complaints you roll back.Note that a customer with a choice is likely to just go somewhere else rather than use your software.
AI written paper4wdloop ( 1031398 ) writes:I suspect that article was actually written by an AI. That would explain why it makes so little sense to human mind.
IT what?Comrade Ogilvy ( 1719488 ) writes:IT in my company does network, Windows, Office and Virus etc. type of work. Is this what they talk about? Anyway, it's been long outsourced to IT (as in "Indian" technology)...
For some businesses maybe but...JohnFen ( 1641097 ) writes:I recently interviewed at a couple of the new fangled big data marketing startups that correlate piles of stuff to help target ads better, and they were continuously deploying up the wazoo. In fact, they had something like zero people doing traditional QA.
It was not totally insane at all. But they did have a blaze attitude about deployments -- if stuff don't work in production they just roll back, and not worry about customer input data being dropped on the floor. Heck, they did not worry much about da
Re:Njovich ( 553857 ) writes:But they did have a blaze attitude about deployments -- if stuff don't work in production they just roll back, and not worry about customer input data being dropped on the floor.It's amazing how common this attitude has become. It's aggressively anti-customer, and a big part of the reason for the acceleration of the decline of software quality over the past several years.
Noangel'o'sphere ( 80593 ) writes:You want your deployment system to be predictable, and as my old AI professor used to say, intelligent means hard to predict. You don't want AI for systems that just have to do the exact same thing reliably over and over again.
Summary sounds retardedJunta ( 36770 ) writes:A continuous delivery pipeline has as much AI as a nematode has natural intelligence ... probably even less.
In other words...JohnFen ( 1641097 ) writes:Analyst who understands neither software development nor AI proceeds to try to sound insightful about both.
All I know isjmcwork ( 564008 ) writes:All I know is that, as a user, rapid-release or continuous delivery has been nothing but an enormous pain in the ass to me and I wish it would die the horrible death it deserves already.
Every morning: git update; make installAs long as customers are comfortable with doing this, I do not see a problem. Now, that will require that developers keep making continuous,
Google matched content |
...
Continuous delivery - Wikipedia
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: April, 23, 2019
