I've been playing around with a handful of WebOS's as of late. In the last six months they have sprung up like hot cakes. These web-gadgets are wonderfully cool and wonderfully useless. The value of having an internet desktop on top of your own desktop seems slight. I could only see it being useful for someone paranoid about privacy or who jumps around between dozens of computers. But even then, there are better tools for doing either job. And if you're paranoid about privacy you're hardly going to put all of your trust in some quirky WebOS company. Especially given their history.
I also don't understand why nearly all WebOS designers decide to implement their "OS" in their own proprietary AJAX/flash system. Every WebOS has to write their own text editor, calculator, web browser, file management system, etc. It seems very inefficient to rewrite all of those programs. Not to mention that the quality of the apps are much much worse then their desktop counterparts.
Instead of writing a whole new operating system with a closed set of apps, it makes much more sense to provide a web-interface to a real computer or virtual machine. The reason why Windows, Mac, and Linux are popular is because its easy to write software for them. If any WebOS ever takes off they are going to have to be able to run lots of software.
One implementation may be a WebOS sever which simply finds a user's virtual machine image and loads it up. It then launches a browser plugin like VNC or remote desktop. You then get access to a whole computer, not some mushy half-ass web-app.
All of these pieces already exist. All you need to do is hook them up. You could use the open source implementation of remote desktop, the open source virtual machine software, and then either find or write some kind of user and security management front-end. I'm kinda amazed no one has done it yet and called it a WebOS.
Monday, July 23, 2007
Saturday, July 21, 2007
Finishing Up Our Release Cycle
At my company we just finished development of our major product and are finally shipping the new version. I have to say that I'm pretty happy that the release cycle is beginning to come to a close. There is nothing more boring or soul-sucking then fixing bug after boring bug.
As would be expected from just about any software project, our project shipped about four months later than our originally intended target. I'm pretty lucky to work in a field which isn't extremely time critical. The four month slip wasn't met with huge disdain. Our product was almost three years in the making so four months wasn't the end of the world.
Honestly, even though we had many problems, I think our release went/is going pretty well. Early in the dev cycle we could have and should have written more validations, we should have tried harder to create a more detailed spec of what we wanted the product to do. However overall I'm pretty pleased with the result.
So when you read those crazy statistics about how 30% of projects fail and 50% have serious problems, I'm happy to say our project fell in the 20% success category.
As would be expected from just about any software project, our project shipped about four months later than our originally intended target. I'm pretty lucky to work in a field which isn't extremely time critical. The four month slip wasn't met with huge disdain. Our product was almost three years in the making so four months wasn't the end of the world.
Honestly, even though we had many problems, I think our release went/is going pretty well. Early in the dev cycle we could have and should have written more validations, we should have tried harder to create a more detailed spec of what we wanted the product to do. However overall I'm pretty pleased with the result.
So when you read those crazy statistics about how 30% of projects fail and 50% have serious problems, I'm happy to say our project fell in the 20% success category.
Thursday, July 19, 2007
I'm not a resource
Has your manager ever referred to you as a "resource"? Its pretty demeaning. I'm an engineer, software developer, person, and/or asshole, but I'm not a fucking resource.
Friday, July 13, 2007
Why Functional Programming Languages Fail
I've recently been dabbling in Haskel. Its a purely functional programming language and I have to say that its pretty cool. I've also messed around with SMLNJ in college and enjoyed it.
The proponents of functional programming languages always say that they are easier to program in, more concise, and are less prone to errors. The detractors always say that they're slow. In response to that proponents of functional programming languages say they aren't that much slower and that most people don't care about performance anyway.
So why isn't everyone programming in a functional language?
My theory is that the proponents of functional languages have their heads up their academic asses. Everyone writing interesting and marketable code cares about performance. Why do you think Intel and AMD make so much money selling the latest and greatest silicon? Could you imagine implementing OpenGL, a JVM, a JIT, or a graphics library in a functional programming language? It would be unbearably slow.
Some argue that if you try hard enough, you can get Haskel to run just as fast as C. They are probably right. But I would bet that its easier to write really fast C code than it is to write really fast Haskel code.
Also with the advent of quality static analysis (which in a couple years I believe will be the default) many of the benefits of a functional programming language can also be found in C/C++.
For everyone else who isn't writing interesting or marketable code, there are languages like Python and Visual Basic. People who write in this straitforward and simple languages prefer very simple languges. Its much easier to understand 'if' and 'for' statements (and also structs and classes) than it is to understand foldr, monads, and polymorphism.
Today we're not programming in Haskel because most of us care about performance, and those who don't prefer easy scripting languages.
The proponents of functional programming languages always say that they are easier to program in, more concise, and are less prone to errors. The detractors always say that they're slow. In response to that proponents of functional programming languages say they aren't that much slower and that most people don't care about performance anyway.
So why isn't everyone programming in a functional language?
My theory is that the proponents of functional languages have their heads up their academic asses. Everyone writing interesting and marketable code cares about performance. Why do you think Intel and AMD make so much money selling the latest and greatest silicon? Could you imagine implementing OpenGL, a JVM, a JIT, or a graphics library in a functional programming language? It would be unbearably slow.
Some argue that if you try hard enough, you can get Haskel to run just as fast as C. They are probably right. But I would bet that its easier to write really fast C code than it is to write really fast Haskel code.
Also with the advent of quality static analysis (which in a couple years I believe will be the default) many of the benefits of a functional programming language can also be found in C/C++.
For everyone else who isn't writing interesting or marketable code, there are languages like Python and Visual Basic. People who write in this straitforward and simple languages prefer very simple languges. Its much easier to understand 'if' and 'for' statements (and also structs and classes) than it is to understand foldr, monads, and polymorphism.
Today we're not programming in Haskel because most of us care about performance, and those who don't prefer easy scripting languages.
Open Source Bashing
Now I'm not an open source zealot or anything, but it pisses me off when the government comes in with their preconceived notions about what open source "is" and why its bad. Check out this report just issued by the FCC. Especially the sentence:
A system that is wholly dependent on open source elements will haveI think that any software going into an SDR system should have a high security burden, open source or not. To just assume that open source code is crap is a bad move on the governments fault. I wouldn't be surprised if someone at Cisco was all buddy-buddy with some guy at the FCC and got this report issued.
a high burden to demonstrate that it is sufficiently secure to warrant
authorization as a software defined radio.
Saturday, June 2, 2007
Back In Time Debuggers
In the near future as processing power gets cheaper and developing software gets harder Back in Time debuggers will become much more prominent. Back in time debuggers allow you step a program backwards just as you would forwards.
The debugging benefits to going back in time are huge. Normally when finding a problem in computer code you run the program over and over again tracking down where the bug first occurred. Sometimes running the program can take several minutes. Sometimes the bug does not reproduce when you re-run the program. With a back in time debugger these problems largely go away. All you have to do is get the bug to reproduce once, and then step backwards to where it first occurred.
The idea of backwards debugging has been around for a long time. However due to recent improvements in hardware and growing complexity in software their time to shine is really coming.
Next, I'll try to come up with a list of the major players in both the academic world and industry.
The debugging benefits to going back in time are huge. Normally when finding a problem in computer code you run the program over and over again tracking down where the bug first occurred. Sometimes running the program can take several minutes. Sometimes the bug does not reproduce when you re-run the program. With a back in time debugger these problems largely go away. All you have to do is get the bug to reproduce once, and then step backwards to where it first occurred.
The idea of backwards debugging has been around for a long time. However due to recent improvements in hardware and growing complexity in software their time to shine is really coming.
Next, I'll try to come up with a list of the major players in both the academic world and industry.
Saturday, April 7, 2007
The Five Software Development Tools You Wish You Had
Last week I went to the embedded systems conference (ESC) in San Josa, CA. This is my second time going and last time I was unimpressed. This time however there were five technologies which really shook my cookie.
All of the products come from different vendors so there is no chance that we will get all of them in a single bundle any time soon. Also, they all cost big $$$ so don't expect them to be GPL'd either.
5) WindRiver's Sensor Points - This is a pretty cool technology which is like an automatic update API for arbitrary code. It allows you to send and run arbitrary code to any system running VxWorks. Thus if you find a bug after your product has been released, you can send a patch to the system while its still running. There are some security concerns here which I never got an answer to, but I'm going to assume (hope) that WindRiver has got those worked out.
4) Virtutech Hardware Simulators - These are some pretty insane simulators. Once you define your hardware model they run the hardware on your host as a Virtual Machine. In many cases it can run even faster than real-time. But thats not all, you can turn on checkpointing in the simulator and record the state of the simulator over time. They you can actually run the simulator backwards and forwards, and even send the checkpoints over the internet so others can see view its state as well.
Sounds great right? The catch is creating the hardware model. Making new models is both technically challenging and can take months. They have a number of models already created but if you have your own funky hardware you're probably going to have to do a lot from scratch. Virtuatech makes their money by creating the model for you... which can be expensive.
3) QNX's Multi-Core Analysis Tool
Multi-core is taking off and managing all of those cores is not going to be trivial. I took a look at this tool and I was pretty impressed. You can see what each of your cores is doing at any given moment. It tracks which programs are running and what types of system calls and interrupts are occurring on each core in a nice easy to use graphical interface.
2) Coverity Static Analysis (and others)
This product has got enough of its own publicity so I'm not even going to go further here. However I will add that it is really cool, and everyone should be using some sort of static analysis (if they can afford it).
1) Green Hills Software and Lauterbach's Back-in-Time Debuggers
These technologies are really cool... you have to see em to believe em. They record the state of your system at every point in time and lets you go back in time and check out memory, registers and more. This would be helpful for tracking down hard bugs and extremely useful just in general.
The catch is that you need special hardware to run this stuff though green hills has some workaround technology called TraceEdge.
All of the products come from different vendors so there is no chance that we will get all of them in a single bundle any time soon. Also, they all cost big $$$ so don't expect them to be GPL'd either.
5) WindRiver's Sensor Points - This is a pretty cool technology which is like an automatic update API for arbitrary code. It allows you to send and run arbitrary code to any system running VxWorks. Thus if you find a bug after your product has been released, you can send a patch to the system while its still running. There are some security concerns here which I never got an answer to, but I'm going to assume (hope) that WindRiver has got those worked out.
4) Virtutech Hardware Simulators - These are some pretty insane simulators. Once you define your hardware model they run the hardware on your host as a Virtual Machine. In many cases it can run even faster than real-time. But thats not all, you can turn on checkpointing in the simulator and record the state of the simulator over time. They you can actually run the simulator backwards and forwards, and even send the checkpoints over the internet so others can see view its state as well.
Sounds great right? The catch is creating the hardware model. Making new models is both technically challenging and can take months. They have a number of models already created but if you have your own funky hardware you're probably going to have to do a lot from scratch. Virtuatech makes their money by creating the model for you... which can be expensive.
3) QNX's Multi-Core Analysis Tool
Multi-core is taking off and managing all of those cores is not going to be trivial. I took a look at this tool and I was pretty impressed. You can see what each of your cores is doing at any given moment. It tracks which programs are running and what types of system calls and interrupts are occurring on each core in a nice easy to use graphical interface.
2) Coverity Static Analysis (and others)
This product has got enough of its own publicity so I'm not even going to go further here. However I will add that it is really cool, and everyone should be using some sort of static analysis (if they can afford it).
1) Green Hills Software and Lauterbach's Back-in-Time Debuggers
These technologies are really cool... you have to see em to believe em. They record the state of your system at every point in time and lets you go back in time and check out memory, registers and more. This would be helpful for tracking down hard bugs and extremely useful just in general.
The catch is that you need special hardware to run this stuff though green hills has some workaround technology called TraceEdge.
Subscribe to:
Posts (Atom)