What makes an OS attractive for programmers?
I'm glad you know what he's talking about. I read his post several times and still am in the dark.
Did he really say he prefers a platform with expensive developers tools to one with free tools?
Did he really say he prefers a platform with expensive developers tools to one with free tools?
The cake is a lie | rackbits.com
- mathematician
- Member
- Posts: 437
- Joined: Fri Dec 15, 2006 5:26 pm
- Location: Church Stretton Uk
Re: What makes an OS attractive for programmers?
Unless you can come up with a really new idea, which has some chance of taking the world by storm (and they are not exactly easy to come by), I would say you chances of getting other programmers involved in your project are virtually nill, because they will all be working on their own vanilla flavour operating systems.Red Shaya wrote: Developing for a new OS requires "pioneer" programmers. I know its not for the average programmer. What I'm interested to know is how to attract those "pioneers"?
Your OS is likely to be all your own work.
One day something will happen to topple Windows and Bill Gates from their thrones, and whoever does it will likely become very rich, but will it be you or me? I doubt it.
Re: What makes an OS attractive for programmers?
Actually, IMO, I doubt just one person will topple the OS market. It's more likely that more and more OS's will come to common knowledge, and the market will fragment, causing there to be not any single dominate OS, but several.mathematician wrote:One day something will happen to topple Windows and Bill Gates from their thrones, and whoever does it will likely become very rich, but will it be you or me? I doubt it.
C8H10N4O2 | #446691 | Trust the nodes.
- crazygray1
- Member
- Posts: 168
- Joined: Thu Nov 22, 2007 7:18 pm
- Location: USA,Hawaii,Honolulu(Seriously)
Re: What makes an OS attractive for programmers?
I strongly feel that the policy of the FSF, Linux maintainers, and the OSS community as a whole are opposing this.Alboin wrote:It's more likely that more and more OS's will come to common knowledge, and the market will fragment, causing there to be not any single dominate OS, but several.
Hardware support is an important factor to make an OS viable. The way Linux, the strongest competitor to Windows, has handled things resulted in a large, readily-available driver set that is open source, but of severely reduced usefullness for any OS endeavour other than Linux because of 1) the unstable driver ABI of the Linux kernel and 2) the GPL license of the driver sources.
Any attempt to argue against either of the two is met with significant heat from the GPL camp. Any attempt to do something significantly different (i.e., closed source) is met with criticism for not following "the true path" (OSS). Any attempt to do something marginally different is met with indifference - "Linux is better anyway". The promise that OSS would "open up" the market has not been fulfilled, monopoly merely been replaced with a duopoly of a kind.
In a way, I consider Linux to be much worse in stiffling OS evolution than Windows ever was.
Every good solution is obvious once you've found it.
- mathematician
- Member
- Posts: 437
- Joined: Fri Dec 15, 2006 5:26 pm
- Location: Church Stretton Uk
One of the biggest problems Linux will have in getting itself accepted as a mainstream operating system is the lasck of easily installble device drivers. Somebody who isn't a programmer, who uses his/her computer for wordprocessing, spreadsheets etc, and doesn't want to spend more than five minutes installing a driver, isn't likely to be enamoured of a system which requires you to compile stuff from source before they can use it. It is likely expecting somebody to be a motor mechanic, or at least vaguely interested in the workings of an internal combustion engine, before they can drive a car.
It may be the Unix way of doing things, but Unix wasn't developed with PC's (which didn't even exist at the time) and Joe Public in mind.
It may be the Unix way of doing things, but Unix wasn't developed with PC's (which didn't even exist at the time) and Joe Public in mind.
Hey, but now you are speaking of those EVIL (tm) drivers that are not fully GPL and part of the kernel proper, because those are of course readily-compiled, fully compatible and up-to-date (you wish...)!mathematician wrote:One of the biggest problems Linux will have in getting itself accepted as a mainstream operating system is the lasck of easily installble device drivers. Somebody who isn't a programmer, who uses his/her computer for wordprocessing, spreadsheets etc, and doesn't want to spend more than five minutes installing a driver, isn't likely to be enamoured of a system which requires you to compile stuff from source before they can use it.
Seriously, that's part of the plan, really. Any driver that is not part of the kernel will be hit by ABI breakages again, and again, and again. Any such driver will have to be either compiled from source (and recompiled after every kernel update), or be held available precompiled for a variety of kernel versions and -flavours (and reinstalled after every kernel update). The big picture is that only completely GPL'ed, kernel-integrated drivers are good ones - because those are the least useful for other OS projects, and because they push the other drivers (madwifi, ati, nvidia...) further into marginality.
Every good solution is obvious once you've found it.
As far as being willing to program for the OS -- I do have some requirements, yes.
1. The OS must be stable. While I am coding and debugging, the OS should never generate a System Error, GPF, or system lockup, unless it is MY code that crashed. Decent messages regarding any exceptions are a plus.
2. The API must be stable. One of the biggest reasons why I abandoned programming for Windoze is related to the fact that there are SIX(!) ways of getting device info -- FOUR(!) possible formats for a bitmap. Get it right the first time, and stick with it.
3. A decent IDE with a good debugger. This is the only reason I still use Windoze at all, and have not yet migrated my development completely onto my own OS.
4. Extensive API documentation, in HTML, with extensive hyperlinking, including "man" pages. I was looking for info on how to switch from one printer tray to the other in Windoze. It took perhaps 20 searches, 300 articles (most of them were completely irrelevant, but I couldn't tell that from the search results), and six hours to determine that someone started to write support for the feature into the Windoze API, but that it never was functional. There is no way to do the simple thing I wanted to do. Let's say that by the end, I wasn't happy.
5. Accurate debugging output from an app test run. To debug a program, one method is to write lots of intermediate output to somewhere. With a GUI front-end, it is very difficult to write lots of debugging output to the screen. You can maybe get away with a few MessageBoxes, but that's about it. So you need to send the debugging info to a file, instead. The most important is usually the info at the END of the file. On a program crash, for example, Windoze will discard some of the last cached data that is supposed to be written to a file, and will output garbage for some of the rest. A real OS must make sure that every last output byte before an application crash is stored carefully.
6. Give me an API and templates and everything else I need, so that I can display a NICE "hello world" (not just in a messagebox), in less than 15 minutes. If it takes me more than a few hours to design the frigging user interface before I can even start to write the actual code that does the work -- then I'm going to dump the project.
1. The OS must be stable. While I am coding and debugging, the OS should never generate a System Error, GPF, or system lockup, unless it is MY code that crashed. Decent messages regarding any exceptions are a plus.
2. The API must be stable. One of the biggest reasons why I abandoned programming for Windoze is related to the fact that there are SIX(!) ways of getting device info -- FOUR(!) possible formats for a bitmap. Get it right the first time, and stick with it.
3. A decent IDE with a good debugger. This is the only reason I still use Windoze at all, and have not yet migrated my development completely onto my own OS.
4. Extensive API documentation, in HTML, with extensive hyperlinking, including "man" pages. I was looking for info on how to switch from one printer tray to the other in Windoze. It took perhaps 20 searches, 300 articles (most of them were completely irrelevant, but I couldn't tell that from the search results), and six hours to determine that someone started to write support for the feature into the Windoze API, but that it never was functional. There is no way to do the simple thing I wanted to do. Let's say that by the end, I wasn't happy.
5. Accurate debugging output from an app test run. To debug a program, one method is to write lots of intermediate output to somewhere. With a GUI front-end, it is very difficult to write lots of debugging output to the screen. You can maybe get away with a few MessageBoxes, but that's about it. So you need to send the debugging info to a file, instead. The most important is usually the info at the END of the file. On a program crash, for example, Windoze will discard some of the last cached data that is supposed to be written to a file, and will output garbage for some of the rest. A real OS must make sure that every last output byte before an application crash is stored carefully.
6. Give me an API and templates and everything else I need, so that I can display a NICE "hello world" (not just in a messagebox), in less than 15 minutes. If it takes me more than a few hours to design the frigging user interface before I can even start to write the actual code that does the work -- then I'm going to dump the project.