Hey, great blog! What will you be doing during your internship at nasa??
Thanks!! :D I’m working on something known as Core Flight Software. I’ll give two explanations for this:
I’m working with low level systems libraries and using already existing NASA system libraries for Linux (CentOS 6.x and Debian 6 or 7 or 8) flight computers. I personally prefer Debian. I build small applets with these libraries. These will need to communicate over various LANs (WAN? maybe not on a spacecraft. I’ll have to ask my mentor tomorrow) on spacecraft such as Orion and the Space Station. What I do is utilize and write in C and run batch processes to simulate communication between the flight computer and the on board mechanics. I then pump this information to a graphics display so that the Astronauts can manipulate and monitor the spacecraft. That’s another beast I haven’t tackled yet.
Also I should mention that I’m part of a big team. I am mostly focused on Audio transmissions.
This is open source so anyone out there who is familiar with Linux, C, Bash, JAVA, and some Python can check it out here (At least these are the ones I have running right now):
I’m basically a coding machine. All day today I sat in front of a computer terminal and stared at green text overlaid on a black background. I like it though! - My hardware engineering friend was really freaked out by this. I have to program this way because I need to build very low level computer systems for space craft. NASA doesn’t like to use unnecessary tools when sending stuff into space. Too many extra programs would take up valuble space on the ship’s computers, so we keep it minimal. I program in C and use the Linux operating system (links in case you want to learn more). My programs can be used on space craft such as the Orion or the Space Station. However, the software I use is versatile enough to be used on almost any spacecraft and that’s what is so awesome about it.
Missing Translation is a fantastic puzzle adventure with beautiful black and white pixel art animation, a secret language and an intriguing world with over 100 logic based puzzles.
Even though Missing Translation has only just been fully released, it’s already won and been nominated for multiple awards, and within the first few minutes of play you can see why. The fantastic art style, audio and world design make the strange world of Missing Translation a joy to explore. The beautifully crafted game world is completely open, so you can wander around solving puzzles in whatever order you like and collect the pieces of a mysterious machine.
All the puzzles are intuitive and logic based, starting off simply, but getting fiendishly tough as they go on. There’s even a Fez-esque secret language to decipher to further test your grey matter. It’s not just the puzzles that make Missing Translation such a great gaming experience though – it’s the whole package. You can’t help but feel you’re playing something special as you explore and solve this perfect pixel art puzzle adventure.
Survive is a tough little wilderness survival game, played out entirely on a single options menu.
You must survive and travel as far as possible through the wild terrain, battling freezing cold conditions and hunger. Gameplay is fairly straight-forward, with you building camps, gathering firewood, fishing, lighting fires and resting - all while trying to move as far from your original location as possible.
It’s a very tricky balancing act, with no room for error. Spend too long fishing when you should be gathering firewood and you’ll be a human popsicle in no time!
A hand animated action adventure game being developed for PC, Mac, Linux, and Wii U (and possible more). I’m so in love with the art, and I’m definitely a little biased with this post as I backed the game on Kickstarter last year.
“As the enigmatic Hollow Knight, players will journey through the depths of Hallownest, a vast and ancient kingdom buried deep underground. Though long fallen to ruin after a dimly-remembered catastrophe, explorers and thieves still brave its dark roads, its caverns and towers, searching for riches and wonders.
“Lately though, something has changed. Villagers and explorers venturing into the caverns have stopped returning. The caverns throb and tremble with a savage energy. A sweet and sickly poison is drifting through the hollows, sending creatures mad with rage and robbing explorers of their memories.”
Porting the Unity Editor to Linux: Stuff I Wish We’d Done Then
At Unite Europe this year, we at Unity released our public roadmap. And while it’s super cool to be able to share all of the amazing stuff we’re doing at Unity, one thing that is close to my heart is the Linux Editor.
The story behind Linux port of the Unity Editor is a lot like the story behind Linux runtime support, which was released in Unity 4.0. It’s basically a “Labor of Love”; some of us at Unity have been working off and on to port (and maintain the port) of the Unity Editor to Linux for quite some time (it’s pretty much the poster child of Unity’s internal developer hackweeks), and I must say, it’s coming along quite nicely. Our plan is to ship an experimental build Soon ™ to let you try it out.
Porting the editor to Linux is a lot of work – much more work than porting our runtime. This is because the editor is where the majority of our actual tech lies (including most of our complex 3rd-party integrations) and because of the asset database, it’s the place where case sensitivity problems really show up. Our editor consists of:
A lot of C++ code, much, but certainly not all, of which is shared by the runtime; this is of course compiled natively.
A lot of C# code, which runs on top of Mono.
Various 3rd-party libraries and middleware, all of which must be compiled for Linux.
Now that we are this far along, let’s look back on a few big things Na’Tosha “wishes we’d done then”…
1. Cared About Case Sensitivity
Unity does not properly run on a case-sensitive file system (which is something that Unity users have discovered if they’ve tried to install and run Unity on a case-sensitive HFS+ file system). This is primarily due to Unity’s asset database, and how it stores paths to map them to GUID values. Of course we tried to be smart in the early days, but if you don’t set up a way to actually verify that what you’re doing works on a case-sensitive file system, then it will never fail that some well-intentioned programmer throws a toLower() in somewhere and ruins the party.
This is definitely something I wish we’d cared about in the past because fixing it after-the-fact is difficult and tedious.
2. Didn’t #if WINDOWS #else OSX
A non-trivial amount of our early work porting the Editor to Linux involved dealing with stuff like:
#if UNITY_WIN // Some Windows-specific codepath #else // Some Mac-specific codepath #endif
Conclusion: If you want to write portable code, always do something sane (read: future-proof) in the #else case.
3. Just Didn’t Assume
The above-two points are the big ones. A few other, smaller, things include:
Assumptions about compilers. An example is our bug reporter in Unity 5, which is in many ways separate from the main editor and is written using some C++11 features. The C++11 standard is, ahem, vague in some places and different compilers choose to interpret the standard, well, differently. This makes porting something using C++11 to a 3rd compiler a pain. Lots of compilation errors that involve this-c++-template-thingy-with-lots-of-angle-brackets does not match that-c++-template-thingy-with-lots-of-angle-brackets-that-has-a-const-somewhere-in-the-middle.
Assumptions about native applications. This includes what sort of stuff goes in the application menus automatically (on Windows, for example, you get some stuff added to the application menu for free (Copy/Paste/etc)). We had to go through and add this stuff in for Linux, because GTK applications don’t get these for free. To be fair, most of this stuff doesn’t come ‘for free’ on OS X, either, but the way it was implemented falls into the #if WINDOWS #else OSX trap I wrote about above.
Assumptions about how file dialogs work. Other platforms have callback systems, for example, so the parent application can tell the dialog if something should or should not be select-able. The default GTK widgets don’t work this way.
Assumptions in general. Conclusion: assumptions really are the root of all evil. :-)
All that being said, the project has definitely been a lot of fun, hindsight is always 20/20, and these are actually the kind of problems I’d expect anywhere when porting a codebase the size and complexity of Unity to a new platform.
Just for fun, I’ll also mention that throughout the porting process, we’ve gone back to the drawing board on a couple of things:
The first pass used raw X11 for windowing/event handling because we were trying to avoid a dependency on either GTK or QT.
Because of (1) the early menu system was actually a menu system written in Unity GUI. I still think this would be pretty cool if we did it someday.
In Unity 5.1, CEF was embedded as the embedded browser system, and this had a dependency on GTK, so we switched to GTK for window/event handling and for the menu system.
But other than this, we haven’t really had to do any re-work.
So what how is the Editor going to work? Here’s what we know:
Only 64-bit Linux will be supported
Same policy as with our runtime; in order to keep our own sanity, we will officially support Ubuntu Linux. Other distributions are on their own, but it will probably work other places.
We’ll most likely support back to Ubuntu version 12.04 (it’s what we’re building on in our build farm currently)
Features reliant on 3rd party stuff (e.g, Global Illumination) should work
Installer will (most likely – it’s one of the things we didn’t do yet) just be a .deb package.
Some of the model importers that rely on external applications (i.e, 3ds Max and SketchUp) won’t work. The workaround is to export to FBX instead.
Anyway, that’s it for now.
Here’s a teaser:
Our Networking demo 2d Shooter being exported to Linux from inside the Linux Editor.
Unity Labs running in the Linux editor. It’s running here on a Retina MacBook Pro, which is why the fonts are small.
Are you excited about the Unity Editor on Linux? What are you going to use it for? What platforms do you want to export to from Linux? Tweet me at @natosha_bard and tell me what you’ll do with it!
Check out IndieGameStand’s new release, AdvertCity!
AdvertCity is a cyberpunk advertising tycoon game. Explore a massive procedural city, and plaster your adverts all over it. Float around cyberspace and post links online. Watch the economy of the city evolve with the effects of your decisions.
Massive procedurally generated cities in a procedural landscape. Switch between meatspace and cyberspace at will to get a different perspective. Manage an advertising empire, posting ads online and using physical advertising. Choose your clients and adverts wisely, as you have a reputation to uphold. Influence the economy and growth of the city with your advertising choices. Buy buildings and upgrade your headquarters to expand your influence. Hire employees and unlock new advertising technologies. Take over megacorporations and make the city yours! Simultaneous synchronised soundtracks, an hour-long original music score featuring postrock, jazz and glitch elements. Roguelike single-save system. Beautiful graphics but runs great on older computers - it will even run on that old notebook where nothing else will! Download for Windows, Linux or OS X.
Blitz Breaker is a simple, tough and very addictive little twitch puzzle platformer in which you can only jump and air dash, charging ever forward until you collide with an obstacle.
Each level in Blitz Breaker is lined with deadly hazards. It’s up to you to figure out the best route, and time your movements perfectly in order to reach the portal at the end. The hazard-filled levels do initially look like a daunting prospect, but once you figure out your routes and get to grips with your little robot’s controls it’s a little less deadly (though you’ll still die a lot!)
A fun, fast paced and fiendishly tough twitch platformer, with that all important ’one more go’ factor.
Butcher is a fast-paced and brutal 2D pixel art shooter harkening back to the classic contra-style shooters of the early 90’s, that gives you one objective - kill everything that moves.
You play a cyborg who’s sole purpose is to eradicate all organic life on the planet, using any means necessary. This generally entails lots of blood-splattering combat as you blast your way through hordes of puny humans, with some satisfyingly OTT weaponry.
The prototype features three levels and eight different types of powerful weaponry to blow away enemies with. It’s a fun, and delightfully gory game, that coats everything with the bloodstains of your fallen foe. You may manage to eradicate all life from the planet, but the clean-up bill afterwards is going to be huge!
How-to Install Silverlight Browser Support on Linux Mint 17.2 Rafaela LTS 32-64bit GNU Easy Guide
Install Silverlight for Linux Mint
The Linux Tutorial Show Step-by-Step How-to Install the Silverlight Firefox and Opera Browser Support by the Pipelight Package for Linux Mint 17.2 Rafaela LTS i386/amd64 GNU+Linux.
Pipelight allows one to run Windows browser plugins in the context of Linux…
gnu, gnu/linux, Guide, How-to, Install, install silverlight support Linux Mint, Linux, Linux Mint, linux mint 17.2 rafaela, linux mint tutorial, Linux Tutorial, pipelight, pipelight Linux Mint, silverlight browser support, silverlight Linux Mint, Tutorial
How-to Install TeamViewer 10 on Linux Mint 17.2 Rafaela 32/64bit Easy Visual-Guide
TeamViewer 10 Quick-Start on Linux Mint 17.2 Rafaela 32/64bit
The Linux Tutorial Show Step-by-Step & Visually How-to Install and Getting-Started with Free TeamViewer 10 on Linux Mint 17.2 Rafaela i386/amd64.
TeamViewer is a Software for Remote Control, Desktop Sharing, Online Meetings, Web…