Saturday, May 31, 2014

The LCARS Manifesto

The LCARS Manifesto
The Perfect LCARS System is Invisible.
Bracer Jack
The intention of this Manifesto is to lay down the base foundation on how LCARS is to be deployed for actual application usage.
Please understand that the creation of this manifesto goes beyond trying to please your average Star Trek fan who is simply after something that looks pretty and cool with random scrolling numbers, if one is looking to LCARS as a decorative element, please refer to “How to Create a Coherent LCARS interface”.
I couldn’t stress this enough, if you are a die hard “LCARS is pretty” fan that couldn’t care less about the intellectual deployment side, please stop reading now and move on, there is nothing here that will please you, this is not a good source if you just want to create a pretty LCARS web site or something just pretty for its own sake.
In mist of the fanatic Star Trek fans out there, I find people that share the same passion as me, people that really care about LCARS and the possibility of it becoming useful, it was as though we all feel that LCARS can really stand on its own feet and have a destiny of its own.
If only someone tried to look at it seriously as a stand alone entity, a concept unto itself and dare to disconnect it from the Star Trek World [in the superficial “pretty interface” sense], this notion alone would cause a lot of bimbo LCARS fan to go nuts and start a witch-hunt and if you are annoyed by the fact that you wouldn’t be seeing random numbers and blinkies in LCARS, you really shouldn’t have read this far, please stop reading and go roll on the floor a little bit.
Ok, let’s begin:

Spirit of LCARS
What exactly is the graphical “spirit” of LCARS ?
If one is to think of LCARS as an interface filled with random numbers and flashing bars, LCARS would never truly see the light of day for serious application usage.
To bring LCARS from its “drama cool” nature to the real world, it is essential that one find that single graphical component that represents it and reconstruct it from there with a very exacting intention of making the whole look functional.
It is beyond question to almost anyone that can identify LCARS a mile away that the single most characteristic component of LCARS is the LCARS swept.
The LCARS Swept
This single element represents the sweeping elegant of LCARS along with its flaw [space efficiency].
An interface design that can be expressed in a single shape...what simplicity, what unity !
Of Buttons:
The unquestionable LCARS button is the round rectangular button:
LCARS Button
However, if the descriptive text is too long, there is only so much the round rectangular button could stretch before it breaks the LCARS ratio.
LCARS Ratio Failed
When this happen, the round rectangular button should transform itself into anyone of these variations in accordance to its surrounding elements.
LCARS Button Variations
Of Conformity:
LCARS twist and bend itself into localized frames to theoretically, frame relevant controls together.
It is advisable that all buttons observe a sense of harmony within its own frame and not standout too much from one another.
All buttons in a frame stays the same
It is ok that buttons of different frames are of different variations.
Different Button types in different Frames
Of Frame thickness:
If the first easily committed crime of LCARS is color, the second would be the total disregard of the very nature of the LCARS frame.
LCARS frames are NEVER the same in thickness on the next turn, this is OMEGA !
We shouldn’t even be talking about this, all LCARS users should just instinctively know this.
LCARS Frame Variations
Of Information Display:
It is fine to add legacy decorative ornaments [all your flashies and what not] to butter up your interface [making something pretty is not a sin] but it is of vital importance that it does not get in the way during the actual operation of the application.
Do not add buttons if you can break the frames itself into buttons unless it’s too thin for the fingers to press on.
An empty LCARS Frame that has lots of blank space but with its frame being totally useful is beautiful.
An LCARS frame that does nothing either than to frame a category is already a 20% sin.
Frame and Buttons
Just make sure that the buttons within a frame looks the same like every other button in the same frame [Of Conformity].
Of Color:
Please read “Creating a Coherent LCARS interface” to understand the nature of color usage.
LCARS should not be restricted to solid colors, gradient or any other crazy form of shading method can be used as long as it doesn’t become a visual distraction.
LCARS Look and Feel
Of Sound:
Free will; just don’t make it too annoying because it’s almost always the case.
Of Animation:
The original idea of LCARS is that it has the ability to “reconfigure” itself to fit specific tasks.
In the real world, an interface that keeps on “rearranging” itself will send shockwaves of heart attack to its user as they constantly struggles to find where the new allocated position for an existing control is, this is absolutely destructive.
So, this is how LCARS would operate in the real world:
If a new task is required, a new screen should appear.
If new controls do appear within an existing LCARS display, it should not off-shift any existing button’s allocation, if this is not possible, revert to the new screen method.
Animations to signal interface changes should be simple and snappy like fade in and out [not cross fade].
Interface animation sequence should not exceed 1 second [1 second being way too long].
Animation is not a core part of LCARS, the more serious purpose it serves, the more pointless and time wasting interface transition animation is.
Developers should think of Interface transition animations as something that can be done without, more often than not, the user will not appreciate it [the first few seconds of wow from a user that have never seen the animation before doesn’t count, interface animations gets real tired real fast when they are just trying to get the job done].

The Mythical LCARS Programming Language
It is conceivable that the ultimate state of LCARS would mean it would have excellent vocal contextual understanding, hence it will be possible to program LCARS via voice.
However due to the fact that the human language is a reflection of the human species, with all its contradiction and misunderstanding that could arise, LCARS will always be best programmed in the “computer language” syntax.
Hereby lay the fundamental ideas behind the mythical LCARS programming language.
Removal of redundant coding:
The LCARS programming language will know what resources [header files in the programmer’s language] it needs by examining the usages of specific keywords in the codes.
There is no reason why a language cannot do that [namespace problems are not an issue if the language prefixes its own header].
A great many will mistaken this for a language that embeds everything and makes for huge footprints, let me restate, the complier ANALYZE the code and figure for itself what resources needs to be included, this is VERY Different to the brain dead “embed all headers” idea.
This is in compliance with “The Omega Idea of LCARS” rule #2:
The computer will not labor a human being into doing task it could in this case, figure it out for itself, a programmer shouldn’t have to sort through documents wondering what header files needs to be included, it’s the computer’s job, you call the function, the language sort through itself and import whatever header files that are required.
AI Garbage Collection:
Humans are an absolutely mess when it comes to cleaning up their act and the LCARS programming language should be designed from the ground up to be able to stand on its own even if the human programmer didn’t clear resources that the system no longer needs.
Today’s version of what is describe above would be the garbage collection system, however in the LCARS era, contextual understanding of the programming language syntax [the ability to figure out what the human programmer is trying to do] will allow systems resources to be freed the minute it will never be used again, for this “AI Garbage Collection System” to be plausible, we will have to wait till computer’s fuzzy logic gets a little smarter or a really witty programming language creator.
The argument that we will not have to worry about system resources in the future is an absolute flaw; it is a well established fact that the human species will always design software that max out the system’s resource in any phase of progress hence, the raise of the AI Garbage Collector is not to be overlooked.
[The transitional phase will be abhorring, there will be a phase where contextual understanding is at its early experimental stage and we’ll end up with compliers that have the wrong idea about what the human programmer is trying to do and for a time, programmers will reject the idea and say that the complier shouldn’t pretend to be a smart ass but this phase will come to pass and future programmers will not be able to imagine those day where their ancestors have to program everything themselves without the syntax analyzer kicking in to help the programmer by asking if this is what they are intending to do and if so, auto fill a large amount of codes all by itself, spelling the end of boiler codes.]
Common sense should override tradition or interior technical logic.
A new programming language arise, and for a time, it was good, then slowly as it adapts new technology/metaphor ideas, old terminologies in the language are being used to describe the new order and newcomers are asked to read about the history of the programming language to know why so and so is named a certain way because apparently, the only way to make sense of it is by understanding its history.
It is in my personal experience that when a programming language reaches this stage, its end is near and will eventually be phase out of existence.
The LCARS programming language will show no apologizes in restructuring its construction syntax as often as required to appeal to current common sense or when a new way of thinking becomes the lay man’s common sense.
This might seem counter productive to gaining support for a computer language but if the LCARS programming language really does its job perfectly when it comes to making its programming workflow so appealing to basic common sense, the future of the programmer is better for it and the chance of our common sense metaphors changing radically is less likely compared to the fact that the restructuring of the language is probably due to bad initial designs.
The key point is not to feel sorry and try to make bad syntax work but to change the language construct entirely if necessary the minute a newer and better sense of doing thing presents itself.
Even if the internal construction of the LCARS programming language haven’t been updated yet, it is none of the language user’s business, the surface can be altered to conform to the new common sense first, the internal restructuring can be done in time [and MUST be done].
No unnecessary inconsistencies, no matter how much sense it makes in the OOP sense:
Some of the current programming languages trend at the current point of writing this manifesto seems to implement seemingly unnecessary inconsistencies.
For example in QT, calling a form’s exec() function will make it modal while using the show() function will not.
The creator of the LCARS programming language must keep on asking himself “Really ?” in a sarcasm way to design the LCARS programming language correctly.
In this case, it would make more “common sense” if the functions are showModal() and showModalLess() since it would allow the programmer to know simply by common sense which one to pick when the code editor pop up the two option hints side by side [which they would be since their lettering order are similar].
No Hungarian Notation
A programmer’s coding time can usually be shortened by really smart code editors that provide lots of hints.
All the programmer has to do is to use his common sense to type out the first few letters of whatever properties he wants to set and the code editor pops out a range of options he can choose from.
Hungarian Notation makes this impossible because it expect the programmer to know the type/constant state/nature of the method/function/variable beforehand.
You would image if the programmer knows that, he would have probably already know what keyword to use and the code editor would serve little purpose to him.
The only sense Hungarian Notation makes is to the internal creator of the programming language and not to the “user” programmer.
Common Sense above Programming Metaphor:
This manifesto was written during a time where the “Object Orientated Programming” metaphor was way hyped as the end all and every programming language seemingly wants to become an Object Orientated Programming language and forgotten about the root of its creation [which may have nothing to do with OOP at all].
Let it be clear that the purpose of any programming “ideology”/“metaphor” is to make the programmer’s job easier, NOT to show off how “Object Orientated” a language is.
This is akin to having a secretary that spend more time showing you her beautiful long hair or whatever instead of using that time to get your job done.
Common Sense must always come before anything else even if and ESPECIALLY when it goes against the ideology of the most current pervasive programming metaphor.
During a certain metaphor’s era, every other form of programming are usually deemed inferior, Object Orientated Programming, Model-View-Controller etc...they all have their ugly sides.
The LCARS Programming Language must never allow the extremes of any programming metaphor to take root so much so that it begin to serve itself instead of Common Sense, alas the self obsessed secretary.
For example, Actionscript 3 has a Sound Object that governs the loading & playing of sounds but require a separate SoundChannel object to close the sound that the Sound object played.
This makes sense to the worshippers of Object Orientated Programming [the more objects the better] but it is an absolute disgrace to Common Sense as one expects the Sound object to have the ability to stop the sound since it’s the Sound object that started/played the sound.
The LCARS Programming Language must never go down the road of worshipping programming metaphors.
Common Sense comes first [can’t stress this enough]:
Just remember, when in doubt, Common Sense is always the final verdict even if it goes against the ENTIRE hierarchy structure of the internal LCARS Language Construct [why would this even happen if one didn’t go all OOP obsessive ?]
Don’t bog the user programmer down with unnecessary jargon:
It is an unfortunate trend that people still associate syntax complexity with power or the idea of a system language.
Remember, if a programming language [or a system language for that matter] is so “powerful”, it wouldn’t ask the programmer for unnecessary craps.
This is a portion of the codes required for iPhone/Objc to play a simple sound:
#import <AudioToolbox/AudioToolbox.h>
SystemSoundID soundID;
AudioServicesCreateSystemSoundID((CFURLRef)[NSURL fileURLWithPath:Soundpath], &soundID);
This is how the QT framework plays sound:
#include <QSound>
Now to the LCARS programmer, both languages lack a leg behind in the sense that these languages should be able to detect certain keywords like “SystemSoundID”, “AudioServicesCreateSystemSoundID”, “AudioServicesPlaySystemSound” or “QSound” and execute the necessary header file inclusion behind the scene during compiling.
Why is it that in today’s world the human programmer still have to do it himself is absolutely unthinkable, that one line of import code is one line too much.
However praise should be given to the extremely well design QT framework for fulfilling the utopia idea of the LCARS mindset, in this case, the programmer just want to play a simple sound, what have the programmer done to offend the ObjC/iPhone sdk to deserve all those crap lines of code is absolutely beyond the LCARS programmer, remember, the programmer just want to play a sound, don’t show him the intricacies of how your internal system handle sound unless the programmer asked for it, atlas the secretary that wants you to comb her hair before she doing anything for you is a bitch.
Don’t be surprise if you were to ask a kick ass programmer how to do something simple [which is a relative term] and he wouldn’t be able to tell you right off his head.
Do not mistaken a good memorizer with a good programmer, though they could go hand in hand, this is rarely so.
Gone were the days where a simple language with a few keywords is all you need to program well.
Almost all programmers except for the purist will built up banks of code libraries that they can copy and paste from into their codes to implement whatever functions they need their program to possess and it is very common that these programmers might not even remember how those pieces of code works even though it could be they themselves that created these codes a long time ago, all they need to know now is where to place them and how to call upon those functions.
The LCARS programming language must be designed for easy modulization.
Believe it or not, there are programming languages that makes modulization a nightmare or an extreme hassle.
This is either due to the requirement to spread a series of codes throughout multiple files just to get a single function working or just pure retardation from the factors mentioned so far.
For example, to play a sound in Symbian C++, a horrified version of C++ from an alternative universe where Hitler rules the world, this is what is required to play a simple sound:
#include <mdaaudiosampleplayer.h>
subclass public MMdaAudioPlayerCallback
then proceed to made public:
virtual void MapcInitComplete(TInt aError, const TTimeIntervalMicroSeconds& aDuration)
virtual void MapcPlayComplete(TInt aError)
Create an instance of CMdaAudioPlayerUtility and play the sound using “OpenFileL”
These are just the generalization of the implementation, NOT the actual implementation which is far too many lines for comfort.
Before anyone say these are not too many lines of codes [remember, that is not the full implementation], please see QT’s “almost” one line code execution:
It really makes you wonder why retardation is an accepted form for programming languages for this day and age.
Don’t get me started on the idea of using functions like “OpenFileL” to play a sound instead of using something like “play”, and yes ladies and gentleman, that “L” in “OpenFileL” is the god forsaken Hungarian Notation that LCARS must never coat itself with.
The mythical LCARS programming language must structure itself so that most of what is required to do something is in one place making it easier for the programmer to “generic-tize” his codes into modules for future usage.
One line code is gold:
It is common practice for programmers to wrap classes/methods/functions/whatever into some simple wrapper/object to make deployment/usage easier.
As a matter of fact, this is such a common phenomenon that it begs the question why does programming language creators makes a habit out of chocking user programmers for lines and lines of initialization codes before any useful functions can be executed.
Granted there ARE cases where this is required but more often then not, this is just plain annoying, like you have to tell the secretary how to use a pen before you can get her to write, what unbelievable retardation.
There had been countless examples of generic wrappers [e.g the Tweener Class for Actionscript 3] that manage to execute what is expected of them in one line compared to the lines and lines of code required in the native language.
It is examples like these that put language creators to shame.
The LCARS programming language must make it its golden priority to achieve one line execution codes that can do that one thing the programmer wants to do.
Example, only one line of code is needed to play sound, with the filename passed as the argument along with some other optional arguments IF necessary, don’t give the user crap like initialize some stupid soundID nonsense that pertains to how the language handle sound [or anything for that matter] internally, it makes the user programer go: “do you want me teach you how to play the tune through the speaker as well you retarded piece of shit”.

The Excessive Desire to Impose Structure
OOP and the price one pays for “Perfect Structure”
In a perfect perfect object orientated world, all similar traits shared by various objects in a program/framework will be in a single object which all other objects then inherit from so as to enable the “change one, change all” concept.
All objects with distinct behaviors would then act as their own object, this idea cascades. the perfect world.
Now back to the real world, as I’ve mentioned, OOP taken to the extreme is like all other form of extremism, it self-destruct itself.
A ridiculous heavy focus on OOP right at the very beginning of a programming project results in a situation similar to useless corporate “meetings” that talks about structuring something that hasn’t yet taken form.
Understands this, the “structuring” of ANYTHING at a premature stage is to lay the road to its early demise because structure at its core, is the direct enemy of spontaneous creativity.
All great programs started out with the programmer having a great idea.
This passion allows them to “just do it”.
The initial code will be all over the place, spaghetti codes, bad programming...etc and it’s perfectly ok.
Lack of structure shouldn’t matter, because it is at this stage where the program will change the most, where the initial idea could be toyed with the most, where its initial intention could accidentally lead to new by-product functions appearing out of nowhere unto itself due to its own complexity, most of the time, it's call a bug, but when it’s not, it makes you go wow in a way that only a programmer or any creator could understand.
It is only after THAT has happened that one should starts thinking about cleaning up, and in time, structure it into a cleaner, more resource friendly format, this is where object orientated programming concept takes root and this is where it is ok for it to take root.
OOP-ing the innards of a program are like adding varnish to a work of art.
Future changes will have to happen in accordance to the structure already laid out by the then finalize OOP structure.
Minor improvements are possible, but radical changes is out of the question unless restructuring the innards OOP structure in one’s program is possible, this is a massive nightmare for BIG programs, this is why sometimes a massively well designed OOP program have to be COMPLETELY rewritten from scratch to implement a new simple idea, a program could be too structured for its own good and its inability to change would subsequently spell its own demise, as does all ideologies of man that are too structured for its own good.
This is why Science is the greatest “religion” man has ever created, it is constantly tearing itself apart and restructuring itself, an ideology with a self correcting mechanism that puts all previous attempt of man’s effort to understand the world through “structure” to shame.
This is why we are at an age where most contemporary religions are turning violent in one form or another, from brute force to dirty politics.
This is akin to the final bright flicker before the candle goes out.
Those ideologies are dying from their “well designed” rigid structure, their current outburst is the signal of the last spark of their candle, this last phase could last for hundreds of years but this phase too will end.
The most violent of them all will be the first to cease from existence not because they are violent as that is the output signal itself, but because this is their last stage, their one last show before oblivion.
An idealized God figure of rigid structure is doomed to fail in the long run because the structure was imagined by imperfect beings pretending that it knows what perfection was to dare lay out the rules for it.
I imagined it would be the religion that has the least structure that will survive the longest.
Science on the other hand, will not hesitate to tear itself apart, or completely rewrite itself if necessary to fit a new idea, this is something that not many religions could do or even hope to accomplish.
Once a religion made a book and say this is all there is to know and there will be no more changes, it already sets the stage to its demise.
The ultimate religion will be the religion that has no hard copy to rely on; hence it could change as often as the consensus of the times.
OOP is a good thing, but don’t destroy yourself by focusing too much on the OOP structure of your program at the beginning.
Do that when the program behaves as you want and then you can work on “beautifying” the innards of your programs with grandiose OOP design structure in version 1.0.1 or something of the sort.

The Omega Idea of LCARS
1: Simplicity:
The LCARS graphical user interface was designed by scenic art supervisor and technical consultant Michael Okuda. The original design concept was influenced by a request from Gene Roddenberry that the instrument panels not have a great deal of activity on them. This minimalist look was designed to give a sense that the technology was much more advanced than in the original Star Trek.
With this understanding in mind, it is indeed a surprise to see LCARS progresses through the show with animations and crazy “flashing” activities, but it is understandable in terms of drama and cool factor.
But the great Gene Roddenberry was right and Michael Okuda’s design had served Gene’s original purpose perfectly.
LCARS was born from a great idea and though it has been altered to look more drama-cool for the series, the original idea had been set, and in the eyes of these two great ones, it was perfect.
In view of using LCARS for actual application usage, we have to go back to the word of Gene himself.
I will also not be compromising my assessment of the idea nature of LCARS to fit present technological limits because just like America, it was a great idea, never fully fulfilled, but always something to thrive for.
2: LCARS is simple, but not retarded:
LCARS should go all out of its way to make sure the users only need to do what the computer cannot do without them.
This applies even in the programming level; at this current moment in time, we still have programming languages that require programmers to type similar codes in two or more files to make a single property accessible, manual unload for visual elements during program termination that have nothing to do with data saving mechanisms, and the need for multiple lines of code for simple string concatenations.
Do not mistake a system language with a retarded language because in today’s world, “system language” is a term often used as an excuse for an inferior portion of certain programming languages.
No more excuses, the future designer of the LCARS programming language must constantly use the “really?...they have to type all these lines to make this possible” sarcasm tone on themselves when designing the language and framework of the LCARS interface and language.
The LCARS programming language must end the “making computer languages complex so that it feels like a system programming language” trend, a system language don’t have to be retarded.
The retard-ness ends now.
3: LCARS should not be catered to the retarded:
Against the basic interface design rules that states that you should treat your users as idiots, my stand is, if one is retarded, one shouldn’t be using the LCARS system at all, it was never catered to them and nor should it.
Make it simple in the sense that it should not ask a human to handle what it can handle itself but not withdraw control to “fake” the look of simplicity.
It’s a dedicate balance and such is the curse of the future programmer trying to create the mythical LCARS system.
4: In the perfect LCARS world, mechanical keyboard no longer exist:
This is not in accordance with today’s requirement and everyone knows that tapping on the screen for an extended period of time is not a good feeling.
Still this idealize part of LCARS will not be compromised.
One can only hope that by the time the mythical LCARS is actualize, some sort of real-time generated tactile feedback technology [super sonic, force field or whatever] would be in place.
5: Speech Recognition:
The mythical LCARS system can be relatively well controlled by voice, unfortunately but accepted, with all the disarray and misunderstanding that the human language delivers, this is not a computer fault.
It is unadvisable to program LCARS using voice under most circumstances even if this becomes a possibility.
6: LCARS will be Holographic in nature:
I cannot imagine LCARS not being 3D and holographic in nature, this has got to be the way for the LCARS interface to go in the long run.
By hologram I don’t mean just your semi transparent hologram that will look nothing more than a poor quality display to future generations, opaque hologram are included.
LCARS Hologram

Video Example [Youtube Link]:
Warp Drive Question
7: A good LCARS system will not look like LCARS:
Imagine an LCARS system so perfect that most of the time, you are answering only yes and no questions because computers are no longer retarded.
Under this perfect LCARS system, if its minimalist spirit is still to be respected, we are looking at a blank screen with two buttons most of the time, now that doesn’t resemble the LCARS most have come to love, but this is the true spirit of LCARS, nothing useless should be shown and if the computer were to display many options to the user, the computer should really starts its own recursive “really...I can’t figure this out myself ?” routine.
8: The Perfect LCARS system is Invisible:
In the farthest reach of our imagination where computer have direct access to our neural net [with all the curse and blessing it brings], LCARS will be working with us on that level, in this form LCARS would have left its graphical nature behind and enter completely into its pure essence, the essence that LCARS is just very simply a perfect computer/human interface system, so perfect that it doesn’t make a sound, a voice, anything, and it just works, this is the Omega state of LCARS and this will be a long time coming indeed.

A final thanks to Gene Roddenberry & Michael Okuda for giving birth to the LCARS design.
This is Bracer Jack, signing off.
I can be contacted at

Thursday, May 29, 2014

Quantum Droplets

Friday, May 23, 2014

New Middleware Technology Quadruples SSD Speed -- Tech-On!

From the article: In a simulation, the research team confirmed that the new technology improves the writing speed of SSD by up to 300% and reduces power consumption by up to 60% and the number of write/erase cycles by up to 55%, increasing product life. Because, with the new method, it is not necessary to make any changes to NAND flash memory, and the method is completed within the middleware, it can be applied to existing SSDs as it is.

Thursday, May 22, 2014

ex-non-"terrorist" reqests payment in Bitcoins.

Icecream and polio


Computers are Rube Goldberg machines where you can't actually see the machinery, only the effects of it, like one of those sculptures made of trash which, when shone upon by powerful spotlight, casts a shadow depicting two people sitting with their backs against each other drinking wine.

In computers the shadow cast by the Rube Goldberg is constantly moving as the machine reacts to the world around it, and spectators demand that the shadow dances across the wall at an incredible pace with ever-increasing detail. And the people interact with the shadow; they watch as it responds to the lightest touch by completing, in a few hundredths of a second, complex mathematics and logic so the shadow can stimulate the hypothalamus of the spectators to produce just a tiny bit more endorphins.

But nobody has ever seen the machine which throws the shadow onto the wall, not even we who built it. We may claim to understand parts of it, but not in any detail, and we definitely do not understand how everything works together. Nobody has seen that the machine is made up of trash, how a used can of soup rolls down rotting plank and barely misses a completely different part of the machine (a tiny white mouse inside a wheel who runs when frightened by a cat in a cage behind it) which I hastily put together right before an important demonstration.

We the builders of this machine have watched the shadow for hours, often pausing it or looking at it in slow motion, in an attempt to get it just right. As we watch, we poke and prod the machine with long sticks until the shadow behaves the way we want, hoping that we didn't bump into anything important which controls another part of the machine.

We are several people working on this ever changing machine, sometimes working together, but most often working on completely different parts of it at the same time. I might add an empty Styrofoam cup and spend a few hours tweaking it until the shadow looks just like a nose, while my colleague sets up a rifle aimed at a bird that will fall into a bucket pulling on a string, which isn't connected to anything yet, but will be very important some time in the future.

And because we do this every day we assume that it has to be this way. Nobody else understands their own machine, so there is no expectation for us to understand this contraption we have built. And look at the shadow, it is beautiful, and works almost flawlessly, and you quickly learn what can cause the machine to fall apart, and try not to do that.

And we use words like architecture and foundation and scaffolding in an attempt to solidify the machine and hide how fragile it actually is. We draw diagrams with boxes and arrows representing the trash and how it interacts with itself, and these diagrams are used to get new team members up to date on how the machine works. The newbies recognize our diagrams as patterns and best practices for sticking trash together, and we have even named some of the more clever combinations of trash. But the machine is constantly changing, and the diagrams are quickly outdated, and become garbage, which someone very clever figured out how to incorporate into all the other garbage. And so the machine is constantly evolving, growing in complexity, always at the verge of collapsing under its own weight, if not for the team of people gently poking at it and supporting it, always careful to check that the shadow hasn't changed (too much).

Wednesday, May 21, 2014

Better than STID....

Tuesday, May 20, 2014

Star Trek TNG - Hypnotic - YouTube


MythBusters: 22 Best MythBusters Quotes : Discovery Channel

Pulled from Discovery.

22 Best MythBusters Quotes

1. Am I missing an eyebrow?
1. Am I missing an eyebrow?
Image Credit: DCL
2. Quack, damn you.
2. Quack, damn you.
Image Credit: DCL
3. I'm OK!
3. I'm OK!
Image Credit: DCL
4. Failure is always an option.
4. Failure is always an option.
Image Credit: DCL
5. Remember, kids, the only difference between screwing around and ...
5. Remember, kids, the only difference between screwing around and science is writing it down.
Image Credit: DCL
6. Holy crap! Run!
6. Holy crap! Run!
Image Credit: DCL
7. I reject your reality, and substitute my own.
7. I reject your reality, and substitute my own.
Image Credit: DCL
8. Well, there's your problem.
8. Well, there's your problem.
Image Credit: DCL
9. This is starting to feel like a bad idea.
9. This is starting to feel like a bad idea.
Image Credit: DCL
10. Jamie wants big boom.
10. Jamie wants big boom.
Image Credit: DCL
11. Our death ray doesn't seem to be working. I'm ...
11. Our death ray doesn't seem to be working. I'm standing right in it, and I'm not dead yet.
Image Credit: DCL
12. Ow.
12. Ow.
Image Credit: DCL
13. Laaaaaaaard.
13. Laaaaaaaard.
Image Credit: DCL
14. High explosives and electricity ... woo hoo!
14. High explosives and electricity ... woo hoo!
Image Credit: DCL
15. Here comes chaos!
15. Here comes chaos!
Image Credit: DCL
16. Remember, don't try this at home. We're what you ...
16. Remember, don't try this at home. We're what you call "experts."
Image Credit: DCL
17. This is why we can never have anything nice.
17. This is why we can never have anything nice.
Image Credit: DCL
18. Big boom. Big boom. Big boom!
18. Big boom. Big boom. Big boom!
Image Credit: DCL
19. When in doubt, C4.
19. When in doubt, C4.
Image Credit: DCL
20. Adam needs a cookie.
20. Adam needs a cookie.
Image Credit: DCL
21. That is MESSED UP!
21. That is MESSED UP!
Image Credit: DCL
22. Sometimes you just need a little lubrication.
22. Sometimes you just need a little lubrication.
Image Credit: DCL

Sunday, May 18, 2014

temptotosssoon comments on Have you ever felt a deep personal connection to a person you met in a dream only to wake up feeling terrible because you realize they never existed?


temptotosssoon 2177 points *
throw away account cause this is really personal.
My last semester at a certain college I was assulted by a football player for walking where he was trying to drive (note he was 325lbs I was 120lbs), while unconscious on the ground I lived a different life.
I met a wonderful young lady, she made my heart skip and my face red, I pursued her for months and dispatched a few jerk boyfriends before I finally won her over, after two years we got married and almost immediately she bore me a daughter.
I had a great job and my wife didn't have to work outside of the house, when my daughter was two she [my wife] bore me a son. My son was the joy of my life, I would walk into his room every morning before I left for work and doted on him and my daughter.
One day while sitting on the couch I noticed that the perspective of the lamp was odd, like inverted. It was still in 3D but... just.. wrong. (It was a square lamp base, red with gold trim on 4 legs and a white square shade). I was transfixed, I couldn't look away from it. I stayed up all night staring at it, the next morning I didn't go to work, something was just not right about that lamp.
I stopped eating, I left the couch only to use the bathroom at first, soon I stopped that too as I wasn't eating or drinking. I stared at the fucking lamp for 3 days before my wife got really worried, she had someone come and try to talk to me, by this time my cognizance was breaking up and my wife was freaking out. She took the kids to her mother's house just before I had my epiphany.... the lamp is not real.... the house is not real, my wife, my kids... none of that is real... the last 10 years of my life are not fucking real!
The lamp started to grow wider and deeper, it was still inverted dimensions, it took up my entire perspective and all I could see was red, I heard voices, screams, all kinds of weird noises and I became aware of pain.... a fucking shit ton of pain... the first words I said were "I'm missing teeth" and opened my eyes. I was laying on my back on the sidewalk surrounded by people that I didn't know, lots were freaking out, I was completely confused.
at some point a cop scooped me up, dragged/walked me across the sidewalk and grass and threw me face down in the back of a cop car, I was still confused.
I was taken to the hospital by the cop (seems he didn't want to wait for the ambulance to arrive) and give CT scans and shit..
I went through about 3 years of horrid depression, I was grieving the loss of my wife and children and dealing with the knowledge that they never existed, I was scared that I was going insane as I would cry myself to sleep hoping I would see her in my dreams. I never have, but sometimes I see my son, usually just a glimpse out of my peripheral vision, he is perpetually 5 years old and I can never hear what he says.
EDIT (24 hours after post): never though anyone would read this, I changed a line so that it no longer seems that my 2 year old daughter bore a child.
I have never seen Inception or the Star Trek episode so many have mentioned (but I will eventually)
I will not do an AMA
I've had many PM's describing similar experiences and 3 posters stating such experiences are impossible, I'd say more research needs to be done on brain functions. Pre-med students, don't assume you know everything.
A few have asked if they can write a book/screen play/stage play/rage comic etcetera, please consider this tale open source and have fun with it
[–]rizzlybear 371 points 
this is pretty creepy. i used to get bronchitis often (every 2 or three months) and one time it was particularly bad. i had friends checking in on me making sure i took my meds regularly and one friend made a lot of echinacea tea and made sure i drank it regularly.. i have no memory of this time. during that time i lived a completely different life. it wasnt ten years though just a few weeks. up until i got sick i was very unhappy with life in general. very depressed a lot of the time and even suicidal. my best friend had died recently and basically my whole life sucked and i could not find ways to fix it.
during these few weeks where i was "out" i managed to find ways to fix most of these problems. my friend even came back. i was super happy, met a great girl. huge promotion at work. EVERYTHING was better.
one afternoon my friend and i were hanging out at our favorite bar and i realized i hadnt shown him any of the tatoos i got while he was dead. i went to show him the one i got in memorial of him and it was literally dripping off my skin. as were all the other tatoos i had gotten since his death. at that point it occured to me that he was dead.. that i somehow had a child with this woman i had met a few weeks ago and that the bar we were in was abandoned and empty and lined with cobwebs which i had noticed before but it didnt seem weird until just that moment.
that whole existance ends there in that abandoned bar.. no more story there. i assume this is when i started walking around on my own again but i still have no memory of that either. in fact i have no memory of anything for a week after i "woke up" and started walking around again. during that week my friends tell me i didnt speak or make eye contact. rarely ate in front of anyone (they left food out for me. they came back to an empty dish. i didnt die.. i must have been eating.) i have no memory of any of this. my first memories kick back in while im at work.
it was difficult to cope with this. to finally get all this weight off my shoulders and finally be happy again. to finally put thatpart of my life behind me was the best feeling ive ever experienced. and then to wake up and find out thats not real is hard. its hard to accept as reality. every night you go to bed expecting to wake up in that dream world and learn that bad world was actually the dream. never happened.
this was three or four years ago now. sometimes when i'm really stressed out little pieces will creep into dreams. the dripping tatoos for example. but the one that haunts me the most is every once in awhile i will have a dream where im on the couch with my son (the same from above) and my wife is in the kitchen doing something. the phone rings and i answer and it's my current girlfriend. she asks what the noise is and i say "thats my son" and as soon as i say that it becomes obvious to me that she isnt the mother and shes not my wife in the kitchen. then i wake up.
i know its my stupid brain screwing with me but something in my head that i cant quite explain KNOWS that this is reality that hasnt yet come to pass. or a reality i missed the turn for. its SO real. its actually caused some problems between myself and my girlfriend because in the back of my brain i know someday i will meet my wife and this is temporary.
i've had doctors try to tell me im making this all up.. its pretty scary for someone to come up and explain almost the same thing without ever hearing me explain it before.. like this could be an actual thing. i feel for you dude. i cant explain how painful it is to lose something that great. and then have to try to explain to yourself that you never had it to begin with.
i have a question though.. do you ever run across things like that lamp "in the real world"? does it terrify the hell out of you? years later i still have moments where i think i see something glitchy like that and the anxiety is instant. like im about to lose my reality again.
wow dude. scary day now. thanks for posting this. i've never talked about this before and its somehow comforting to write it all down.