EvilZone

So if you know its a huge project and you just want something to work at for a lonnng time, just a few things for consideration:


#1) the programming world changes very quickly. The more time you take to release something, the more out of date it will be. So if you start programming now, and end up releasing a product in 10 years, all the programming you did for the first half will be completely irrelevant. take Duke Nukem Forever for example. This game sucked basically because it took so long to develop. read up on it and youll see what I mean. If you don't care about any release though, then:


#2) your really talking about multiple projects here. there are large companies that literally only do engines. and most game development companies do not create their own engines, they use their partner's because it would be insane for them to try. Even with the massive amount of people they may have. Maybe you don't understand exactly what an engine is though, so I may look into that a little more.


#3) your gonna have a hard time convincing anyone to join you on this little adventure. As you can see most people are just gonna laugh and call you a noob.


Basically, this is a really really REALLY big project that is indeed very close to impossible for one person, even a very experienced game developer. I would just lower the ambitions a little bit, start out with your basic ideas first, then expand upon it as you go. Make one small project first so you get an idea of what your doing. I recommend a 2D physics based game using box2d in c++. after this, you will have a better idea of what you are getting into and know where you want to go with it. Maybe if you do a really really good job with a very basic game, others will decide to help and your game could slowly evolve into what you originally wanted it to be. With the help of the entire open source community.

math hack    Thats cool.


another one:


.9999repeating = 1


9.999... = 10x


9.999... -  0.999... = 10x - x


9 = 9x


1 = x

Hey all,


As I have already stated, I am very interested in the Software Defined Networking field. I thought I would share a resource on it in case anyone would like to learn a little about it. For those of you who havent heard of it, its a new approach to creating computer networks, based around a protocol called "Openflow". The first implementation of openflow was released 6 years ago, and is being very actively expanded upon. Recently, openflow 1.4 was released, but the LTS version is openflow 1.3 so you would do well to learn that version.


So what does it do? The basic idea is to have a programmable switch, that acts exactly as you tell it to. It could do almost anything, performing functions from IDS to IP Routing and anything in between, which is all up to the programmer to decide. The switch "speaks" openflow(which is the protocol that is used to program it) to a controller, which is the program that decides how the network should perform. The controller is simply a program running on a computer that is attached to the switch. There are many controllers, and each has its own API, which allows you to write your own controller with its own rules. More of this will be explained in the tutorial I am linking.


Openflow will send the switch commands, which come in two ways; packet_outs and flow_mods.


Packet_outs are the very basic way for openflow to direct traffic through a network. When a new type of packet is received by a switch via any port, and it does not know what to do with it, it sends it straight to the controller(using openflow) via a packet_in. the packet_in is parsed at the controller, yielding the ethernet packet, IP packet, or ARP, etc. Based on the program, the controller decides what to do with it. if it decides to send the packet out to another node in the network, it will assemble the packet as it sees fit(could do anything), and send a packet_out message to the switch which contains a different the port that the switch should send the packet out from.


Flow_mods are the way that openflow switches are supposed to be used. This is how you actually "program" the switch. Flow mods are messages that the controller can send to the switch at any time, which will tell the switch how to behave for certain packets.


Example: The switch receives a packet from 10.0.0.1, whose destination IP is 10.0.0.2. The switch sends the packet to a controller, via packet_in, and the controller sends a flow_mod back to the switch, stating that any more packets from 10.0.0.1 meant for 10.0.0.2 should be sent out the port connected to 10.0.0.2. From now on, when the switch receives a packet from 10.0.0.1 towards 10.0.0.2, it will no longer send a packet_in to the controller, but will route the packet directly to the destination ip.


As you can imagine this is extremely powerful. You could have easily said "send anything from 10.0.0.1 to 192.168.1.100, or any other address. Or you could have just dropped the packet cold upon arrival. or sent it out across the internet.


Thats the basics of SDN, but only the very basics. there is a lot more to learn, and I highly recommend it as I believe it could be the future of networking.


I also wanted to clarify what exactly mininet is, because you will use it if you try to do this tutorial.


mininet is a lightweight network emulator. it allows you to create thousands of nodes(hosts or switch or controller) virtualized in your computer, and it wont kill your computer like most virtualization software will. I wont go into the details of how mininet actually works, but it is well put together. The reason it is used here is because it "speaks" openflow! You can test all of your controllers directly from mininet, without any hardware. It has an option to specify exactly what controller to use for each switch, which is quite nifty. you can do pretty much anything with it, even attach it to a real physical network. you could have 100 nodes on your mininet instance, and attach it to your desktop, and your desktop would be able to talk to any of those 100 nodes as if they were real computers. Cool right?


Feel free to ask me any questions. I have finished the tutorial, and can lead you along if your stuck. I used the Pox controller, I recommend it. Have fun!


https://github.com/mininet/openflow-tutorial/wiki


Also, wasnt sure if this should be in tutorials or here, so I put it here. feel free to move it

Try something physical. Maybe start a new workout routine or something. I bust my ass during the day working out , so when I get home, sitting on my computer and coding a little sounds wonderful to me. Could also try picking up another kind of art, like say jiujitsu, knife throwing, something COMPLETELY different that your interested in. Somehow this makes it easier for me to enjoy this stuff when I actually have time to do it. This is just what works for me!

Strange. all I did was change that line and run 'systemctl restart sshd' and it worked. Well, glad  you figured it out at least.

Hey lucid, I see that you solved this already, but I didnt see until now and found another solution in case your curious. sorry im late :/

I slapped your configs and user names into a virtual lab of arch virtual machines I have, and tested your problem. I had the same issue, it turned out to be a tiny config error. Basically what was happening was this:

My client sent a public key packet and waited for the server to accept. The server did not have the key in the specified authorized key folder(even though the public key was correct and in /home/shell/.ssh/authorized_keys), so the communication died right there since the client got no message from the server verifying the key.

The Fix: i specified the full path to authorized_keys in sshd_config like this: "AuthorizedKeysFile          /home/shell/.ssh/authorized_keys"

I believe the sshd process was running as root, so when it calls ~/.ssh/authorized_keys, it was looking in the root directory instead of shell home directory. Again, sorry im late but maybe this makes more sense and is a bit more clean...

Cheers