Hi, I see a lot of potential in the simulation of small networked devices, like wireless sensor nodes or internet-of-things type of devices. Such devices are built around microcontrollers like PIC, AVR or ARM-based stuff. It's just a matter of hooking up the electronic simulator to the given architecture's simulator, and then we could have really useful design tool ;)
Regards, Zoltan 2012/5/9 Alan Grimes <agri...@speakeasy.net>: > ktechlab was a brilliant, innovative and generally awesome piece of > software for the first decade of the 21st century. Now we're in the > second decade of the century and it's time to raise the bar to the next > level. > > Everyone is ga-ga about web-based applications these days. They are > taking perfectly good applications, downgrading their user interface by > five or more years so that they can run in a constraining, slow, and > crappy web-browser. > > They're missing the point. > > There is no point in running crap in a web browser just because it's the > trendy thing to do. > > The point is the *NETWORK*, not the web. Modern software must be network > centric. > > There are several major advantages to network centered software. > > -> Collaboration. > -> ubiquitous access. > -> real-time sharing of component libraries and platform development. > > Basically, these are must-have features for contemporary software. > > So what I propose is a client-server architecture with a peer-peer > infrastructure. So if you want to keep some stuff private, you'll need > to run your own server, otherwise it would be optional. (kinda like how > free-civ works.) > > The front end will be some kind of game engine. Crystalspace is the > common open source engine, I'm not sure it will support the dynamic > content generation we need. The other interesting engine is OpenCobalt > which is written in Smalltalk. Last I checked it was still definitely > alpha-ware but has shown dramatic progress from earlier versions. > > The back end will consist of a parts database and a world-map which will > constantly evolve as people add parts. The server will store the circuit > and the state of the inputs. The client code will run the simulator, but > only on the circuits near the user. (they would otherwise be running > much too fast for any kind of server-side simulation). > > I want the client to be 3D, so the schematics can be drawn in 3D. This > is important because nanotechnology will eventually be catching on. > > One very practical application would be managing power connections for > IC components and logic gates. Right now we aren't simulating the power > needs of logic gates. These are frequently omitted from schematics for > clarity. For example, a network drawn in the XY plane could have it's > power layout mapped in the X-Z plane... > > 3D design is also very important for MOS gate design as well as new > layered ICs and PCBs. -- Gerber file exporting will be critical for > making Ktechlab a viable design tool. > > Also, it will provide a crossover environment for mechanical > simulations/robotics. (there was some stub code for this in the old tree..) > > Now the issue of an "on-line" simulator raises the problems of service > reliability and updating. A peer-peer server infrastructure should > alleviate the cost to the project maintainers for network operation. The > bigger issue is managing software updates to the network. Therefore > there needs to be client-server protocol versioning so that clients can > negotiate with the server. Also, there needs to be a method for > extending the server without taking the whole network down. There are a > number of general approaches for distributing updates. Basically, the > server must be profoundly modular so if someone makes a true > oscilloscope object (as opposed to the chart recorder ktechlab 0.3 had), > that innovation can be integrated and distributed to clients in near > real-time without introducing security problems (!!). So there might > have to be some kind of security check on the server so that, for > example, any code that imports/links against system libraries is > rejected as "prohibited: security hole". > > The idea is to create a platform for open hacking that can evolve > collaboratively at a near break-neck speed. If what I propose here is > even half-way successful, it could be totally slashdotted, (survive only > because of the peer-peer server architecture). > > There also needs to be some kind of way to manage user identity, so that > access to hub servers can be limited and metered, while users with > private servers can place locks on their own private inventions while > displaying their other stuff in public in such a way that visitors can > copy it but not edit the original. > > -- > E T F > N H E > D E D > > Powers are not rights. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Ktechlab-devel mailing list > Ktechlab-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
