Do you implement user-space programs yourselves?

[Sourcer]

Or do you're writing a "STANDARD"(POSIX, WIN32) compatible kernel, and you just import existing user-space executables?

[Octacone]

Or do you're writing a "STANDARD"(POSIX, WIN32) compatible kernel, and you just import existing user-space executables?

Side note: yourselves -> yourself

User space programs are meant to be ran in user space. They are specific to your OS. Win32 and Posix have nothing to do with your operating system at the moment. Posix is a standard you choose to follow or you don't. Win32 executables are specific to windows only, there is a way of running Win32 applications on your OS, but that is very hard (see React OS for more info). There is no such thing as importing existing user space executables, you have to make them yourself, to be your OS specific. You could in theory make cross compatible apps that could run on every OS, but that is just a theory.

[Sourcer]

Or do you're writing a "STANDARD"(POSIX, WIN32) compatible kernel, and you just import existing user-space executables?

Side note: yourselves -> yourself

User space programs are meant to be ran in user space. They are specific to your OS. Win32 and Posix have nothing to do with your operating system at the moment. Posix is a standard you choose to follow or you don't. Win32 executables are specific to windows only, there is a way of running Win32 applications on your OS, but that is very hard (see React OS for more info). There is no such thing as importing existing user space executables, you have to make them yourself, to be your OS specific. You could in theory make cross compatible apps that could run on every OS, but that is just a theory.

When you follow POSIX you can import existing executables with minor changes, you don't need to rewrite the whole thing(Like when you're importing bash from linux, for example)
I strongly disagree with your post.

[wichtounet]

It's a lot of work to port existing programs to your operating system. If you want to port C programs, you need at least to port the entire C library to your OS and then you can start porting programs. You also need to port system dependencies (Unix sockets for instance). You also sometimes need to port the libraries it depends on.

At the beginning, I think it's better to write new user-space programs to test the operating systems. When the OS is in excellent state, it starts to be interesting in porting programs to the operating system. It's probably a great point when you can port large programs into your operating system and they are working fine.

[BrightLight]

Many applications can be ported without many dependencies.
FASM, for example, probably requires memory management, file manipulation and that's it. Newlib (C library) requires a set of 17 system calls only (according to the Wiki) which should be implemented on most any kernel. GCC, Make, bash, binutils, and many other stuff can be ported once you have Newlib.
octacone: others have also expressed opinions similar to mine; I also strongly disagree with your post. Especially on POSIX, porting applications is somewhat easier than other systems (due to the ease of porting Newlib) and due to POSIX being an open standard and implemented in several open-source projects (Linux, OpenBSD, ...) unlike Win32, which is not impossible, but not a good idea as it's not really documented.
Personally, though, I'd probably port FASM to be self-hosting, and write my own C library and my own applications.

[Octacone]

I did not explain it very well. I was talking about porting application without Posix standard. You guys are talking about porting applications when you already have achieved everything needed (Posix and libraries, etc...), that was not my point.

Also he was talking about "importing", porting != importing.

...There is no such thing as importing existing user space executables....

[DavidCooper]

I have no desire to support any programs not designed specifically to run on my OS. Most of them are piles of bloated, bug-ridden crap which need to be improved in too many ways for me to care about supporting them, but they're also a security risk. I will focus on building sufficient intelligence into my OS to enable it to write its own apps in direct response to the user's requirements.

Side note:-

Side note: yourselves -> yourself

"Yourselves" is the fully valid plural of "yourself" and is fine in the thread title, but "yourself" would work there too.

[Octacone]

I have no desire to support any programs not designed specifically to run on my OS. Most of them are piles of bloated, bug-ridden crap which need to be improved in too many ways for me to care about supporting them, but they're also a security risk. I will focus on building sufficient intelligence into my OS to enable it to write its own apps in direct response to the user's requirements.

Side note:-

Side note: yourselves -> yourself

"Yourselves" is the fully valid plural of "yourself" and is fine in the thread title, but "yourself" would work there too.

Did not know you could say "Do you like coding yourselves". That sounds weird in my opinion. Never heard of somebody saying it that way.
+1 for that post.

[MichaelFarthing]

"Yourselves" is the fully valid plural of "yourself" and is fine in the thread title, but "yourself" would work there too.

Did not know you could say "Do you like coding yourselves". That sounds weird in my opinion. Never heard of somebody saying it that way.
+1 for that post.

The second example, though grammatically coorect, sounds wrong, because in this example 'yourselves' is used as a direct object and imples that the individuals specified by the initial (plural) you should design their own DNA. A diifcult undertaking even for those good at developing operating systems.

In the first example, referred to by David, and stated in the thread title, 'yourselves' is an emphatic adverb (that is a grammatical term that I have just invented) that emphasises that the subject (you plural) really is doing all the work.

Hence the first sounds OK and the second sounds daft - but it is not a fair analogy because the sentence structure is quite different!

[Brendan]

Hi,

Or do you're writing a "STANDARD"(POSIX, WIN32) compatible kernel, and you just import existing user-space executables?

Ideally, neither.

My plan is make the OS so impressive (compared to existing OSs) that people will want to write native applications (and drivers) designed specifically for it (that take advantage of whatever features made the OS impressive and help to make the OS even more impressive); so that (eventually, hopefully) I won't have to write applications (or drivers) myself.


Cheers,

Brendan

[Octacone]

Hi,

Or do you're writing a "STANDARD"(POSIX, WIN32) compatible kernel, and you just import existing user-space executables?

Ideally, neither.

My plan is make the OS so impressive (compared to existing OSs) that people will want to write native applications (and drivers) designed specifically for it (that take advantage of whatever features made the OS impressive and help to make the OS even more impressive); so that (eventually, hopefully) I won't have to write applications (or drivers) myself.


Cheers,

Brendan

For real? Is this sarcasm? I would really like to see that. If it is going to be more secure than Windows, why wouldn't we use it? Really looking forward to it.

[Antti]

If it is going to be more secure than Windows, why wouldn't we use it?

An interesting viewpoint. If we evaluated security, should we first define the requirements for the OS? To maximize security, just have an OS that does nothing or does not exist at all. Apologies for being a little bit negative but security in general seems to carry so much weight that we forget its role of being just a part of the whole. If someone is going to develop a modern OS, taking security into account is so obvious that it should not be "the feature" on the features list. If a boat manufacturer is selling new boats, is it specifically mentioned that those boats are floatable?

On the other hand, it might be a valid priority if an OS specifically targets to compete in this area. However, it sounds a little bit boring basis if we think about a general-purpose OS for which people on a larger scale are assumed to write applications. What about getting interested in its unique features, i.e. "the features" on the list?

[Schol-R-LEA]

Hi,

Or do you're writing a "STANDARD"(POSIX, WIN32) compatible kernel, and you just import existing user-space executables?

Ideally, neither.

My plan is make the OS so impressive (compared to existing OSs) that people will want to write native applications (and drivers) designed specifically for it (that take advantage of whatever features made the OS impressive and help to make the OS even more impressive); so that (eventually, hopefully) I won't have to write applications (or drivers) myself.

Please tell me you are joking here, because that is pure insanity talking otherwise. It combines a level of hubris that would make Stephen Wolfram pause, with a a degree of self-indulgent fantasy that makes my expectation of users putting up with Lisp as part of the system look well grounded in reality.

Here's a clue for you, Brendan: operating systems are not, cannot ever be, a killer app. No one chooses an OS based on the OS itself. Period. Most don't choose one at all, but just use whatever one comes with their computer - the majority of users don't know what an OS is, or the differences between them - or the one that their company uses, and never consider the question at all. Of those who do, most go with the one that gives them the tool they need, and if the tool they need is on all the available platforms, they fall back to the greatest convenience at the moment.

Some aspects of an OS may make it more likely that people would adopt it, but unless they have something they can do on it that they can't do as easily with their competitors. - say, PhotoShop on the early Macs - or some personal or political reason for doing so (the combination of low TCO, programmer friendliness, and FOSS good-feelz that drives the Linux world), they won't even notice it.

And no, I don't think my own UX designs, no matter how innovative they may prove to be, would by themselves draw anyone to them. I am focusing on research for a number of reasons, and one of them is that I am interested in systems, not apps, and without apps a system - no matter how well designed or well-appointed - is just a toy.

TECHNICAL SUPERIORITY IS NOT ENOUGH. None of the systems in widespread use today got to their positions through technical prowess. Unix caught on because it was the first portable system that was available with source code for a reasonable license, making it suitable for study by universities. Windows' success developed through a historical happenstance of Microsoft hooking their star to IBM, and then knowing when to jump ship as Big Blue started to drop the ball. MacOS caught on because a) Apple was already popular for their earlier systems, b) they were leapfrogging other systems with having a GUI at a semi-affordable price, and c) they had better graphics than PCs did (even with the smaller, B&W screens). Linux caught on because of the backlash against Windows and Macs, and because it built on the previous success of Unix at a time when everyone else doing Unix were busy in court slitting each others' throats. Technically superior systems such as Genera, Smalltalk-80, AmigaOS, and BeOS never got any traction, because they didn't really offer anything that people actually needed - and if the Internet has shown anything, it is that security and reliability come dead last in the list of concerns people have when choosing software, especially for those businesses where those should be the primary concern - and if you think you can cure the world of that sort of stupidity, then you are engaging in a higher-order stupidity of your own.

[Brendan]

Hi,

Or do you're writing a "STANDARD"(POSIX, WIN32) compatible kernel, and you just import existing user-space executables?

Ideally, neither.

My plan is make the OS so impressive (compared to existing OSs) that people will want to write native applications (and drivers) designed specifically for it (that take advantage of whatever features made the OS impressive and help to make the OS even more impressive); so that (eventually, hopefully) I won't have to write applications (or drivers) myself.

Please tell me you are joking here, because that is pure insanity talking otherwise. It combines a level of hubris that would make Stephen Wolfram pause, with a a degree of self-indulgent fantasy that makes my expectation of users putting up with Lisp as part of the system look well grounded in reality.

I am entirely serious (including the part about "eventually, hopefully").

Here's a clue for you, Brendan: operating systems are not, cannot ever be, a killer app. No one chooses an OS based on the OS itself. Period. Most don't choose one at all, but just use whatever one comes with their computer - the majority of users don't know what an OS is, or the differences between them - or the one that their company uses, and never consider the question at all. Of those who do, most go with the one that gives them the tool they need, and if the tool they need is on all the available platforms, they fall back to the greatest convenience at the moment.

This isn't just wrong, it indicates a significant amount of ignorance.

How many people that need "hard real time" choose an OS that wasn't designed for it (like QNX)? How many people that need high availability enterprise servers choose an OS designed that wasn't designed for that (like NonStop OS or HP UX)? How many people chose Mac OS or OS X because they preferred the GUI? How many people chose Windows because of DirectX/gaming? How many people switched from MS-DOS to Windows because of the "killer GUI feature"?

Out of all the hobbyist OS projects I've seen, if I had to choose the one that has the highest chance of (commercial) success, I'd choose BareMetal OS. Do you know why? It provides something that other/existing OSs don't that makes it attractive for a niche market (a "lean and mean" environment for HPC).

Some aspects of an OS may make it more likely that people would adopt it, but unless they have something they can do on it that they can't do as easily with their competitors. - say, PhotoShop on the early Macs - or some personal or political reason for doing so (the combination of low TCO, programmer friendliness, and FOSS good-feelz that drives the Linux world), they won't even notice it.

Yes.

Are you saying that because you're not able to think of "something users can do that they can't do as easily with other OSs", you've made the mistake of assuming that nobody else can think of anything either?

TECHNICAL SUPERIORITY IS NOT ENOUGH. None of the systems in widespread use today got to their positions through technical prowess.

Win9x replaced MS-DOS because it was technically superior, and the NT kernel (e.g. WinXP) replaced Win9x because it was technically superior. QNX dominates an entire market because it's technically superior for that market. The entire "game consoles" market exists because it's technically superior (in the "zero compatibility problems" way and in the "less bloat, hassles and cost because its designed for a specific purpose" way) to PCs. The entire smartphone industry (and OSs like Andriod, etc) exist because they're technically superior to the "dumb phones" that they replaced.

Unix caught on because it was the first portable system that was available with source code for a reasonable license, making it suitable for study by universities.

Unix caught on (originally) because there were multiple competing commercial vendors marketing it to companies, and because it was technically superior to other OSs at the time.

Windows' success developed through a historical happenstance of Microsoft hooking their star to IBM, and then knowing when to jump ship as Big Blue started to drop the ball.

MS-DOS's success was historical happen-stance (or clever management by Microsoft vs. mismanagement by IBM), but Windows is not MS-DOS and is an entirely different OS. Both OS/2 and Windows replaced MS-DOS because they were both technically superior, but OS/2 lost to Windows (because of more "clever management vs. mismanagement").

MacOS caught on because a) Apple was already popular for their earlier systems, b) they were leapfrogging other systems with having a GUI at a semi-affordable price, and c) they had better graphics than PCs did (even with the smaller, B&W screens).

MacOS caught on initially because it was technically superior (the first OS to provide a GUI).

Linux caught on because of the backlash against Windows and Macs, and because it built on the previous success of Unix at a time when everyone else doing Unix were busy in court slitting each others' throats.

While "backlash against Windows (and Macs)" might have influenced an insignificant number of people, for the desktop market, Linux never caught on (always was, and always will be, an irrelevant joke). For the server market, you're right (Linux built its success on backlash against the same expensive commercial Unix clones that were responsible for the success of Unix, combined with "fortunate timing" for the FreeBSD legal dispute).

Technically superior systems such as Genera, Smalltalk-80, AmigaOS, and BeOS never got any traction, because they didn't really offer anything that people actually needed - and if the Internet has shown anything, it is that security and reliability come dead last in the list of concerns people have when choosing software, especially for those businesses where those should be the primary concern - and if you think you can cure the world of that sort of stupidity, then you are engaging in a higher-order stupidity of your own.

I have no idea what Genera is. Smalltalk-80 is a programming language and not an OS. For home computers, Amiga (and AmigaOS) were successful originally, but Amiga (the hardware) got killed by superior (cheaper, faster) "PC hardware" and the entire company (Commodore) died (taking AmigaOS with it). BeOS was technically superior software running on inferior hardware until they switched to 80x86, but by then Windows9x was out and it was technically inferior software running on the same hardware.

Now tell me; what do you think the alternative is? Assuming you want to maximise the chance of an OS succeeding (which is always going to be extremely difficult regardless of what you do); would you:

• A) Deliberately make the OS technically inferior, because some deluded fool said "technical superiority doesn't help".
  B) Spend a decade developing an OS, and hope that the OS will eventually be so good that people assume it's just a worse than normal Linux distro (because it was easier to port everything and end users can't tell the difference).
  C) Try to make it technically superior in some way, for some purpose.

Cheers,

Brendan

[Schol-R-LEA]

How many people that need "hard real time" choose an OS that wasn't designed for it (like QNX)?

A lot more than you probably think. Most, I would say. But then again, most of them don't know that that is what they need, so...

How many people that need high availability enterprise servers choose an OS designed that wasn't designed for that (like NonStop OS or HP UX)?

Far too many. Almost all, in fact. There are a vast number - thousands, maybe tens of thousands - of 'enterprise datacenters' that under-perform because they are running stock Windows or Linux without even the most basic tuning, never mind choosing a more suitable OS when they should. Furthermore, if you ask the managers of these centers why they don't fix this, they say 'it works well enough and fixing it would cost too much' - and if you then point out the c/b on fixing it, they will kick you out cursing at you, because whether they are willing to admit it to themselves or not, their jobs, status, and operating budgets depend on the datacenter under-performing (ie.g., if it worked correctly, they'd make themselves redundant). As do those of their own managers, so going over their heads won't work either.

How many people chose Mac OS or OS X because they preferred the GUI?

Quite a few, admittedly, especially in the past. I would say more - at a ratio of 10 to 1, roughly - chose it for it's mystique or because "that's what artists use", though.

How many people chose Windows because of DirectX/gaming?

Most people don't choose their OS based on gaming, and those who do... well, there is only one game in town for that, isn't there? But it is the killer app (gaming) that is deciding the OS choice, not the other way around.

How many people switched from MS-DOS to Windows because of the "killer GUI feature"?

Uh, I remember that period quite well, actually, and the answer is "almost no one". They went to Windows because that was what new systems were sold with, and what new software ran on, and because it was 'the new thing'. While few actually complained (more than you'd expect, but not all that many really), I know of pretty much no one who used Windows 3.1 or Windows 95 because it was a GUI system. I do know many, many offices that only upgraded their DOS boxes because they were told that they would turn to dust on 1 Jan 2000, however. I was still doing those upgrades at one place I worked when I left them - on 25 February 2000. I wish I were joking about this.

Out of all the hobbyist OS projects I've seen, if I had to choose the one that has the highest chance of (commercial) success, I'd choose BareMetal OS. Do you know why? It provides something that other/existing OSs don't that makes it attractive for a niche market (a "lean and mean" environment for HPC).

You are still assuming that people choose systems on a rational basis. This simply isn't true for most individuals, nor for most corporations, NPOs, or government agencies. Not even close.

TECHNICAL SUPERIORITY IS NOT ENOUGH. None of the systems in widespread use today got to their positions through technical prowess.

Win9x replaced MS-DOS because it was technically superior, and the NT kernel (e.g. WinXP) replaced Win9x because it was technically superior.

This is so wrong it is hilarious to me. They were technically superior, yes, but that fact had almost no impact on the replacement of the MS-DOS by Windows 95; and while the NT/XP kernel replaced the 9x kernel for solid technical reasons, they were reasons related to Microsoft's ability to fix and maintain the OS - to the users, the different was invisible.

The entire smartphone industry (and OSs like Andriod, etc) exist because they're technically superior to the "dumb phones" that they replaced.

Yes, but the operating systems themselves are not a significant factor; the significant factor was the touchscreen interface and other hardware, and the ecosystem of user apps. iOS and Android are necessary support for the smartphones, but the OSes themselves were and remain pretty nearly irrelevant (which one could argue is what a good OS should be, just like a good manager or administrator), and the decision to choose one over the other is generally based on one's opinions of Apple and Google as companies, and on the cost of the phones, not the technical qualities of the OS.

Unix caught on because it was the first portable system that was available with source code for a reasonable license, making it suitable for study by universities.

Unix caught on (originally) because there were multiple competing commercial vendors marketing it to companies, and because it was technically superior to other OSs at the time.

That came later, much later. The groundwork for Unix's success was in the mid-1970s, when AT&T were legally enjoined from selling computer hardware, and required to offer the source code for any software they sold. This led to them selling the PDP-11 version of V6 and V7 to customers, mainly universities, who then used it as the basis for both general operations and their OS courses - hence the famous Lions book. Unix was never common in the business world, but it dominated the academic world from 1976 to the mid-1990s (pretty much any VAX cluster that wasn't running VMS ran either Ultrix or BSD), and when start-ups like Sun and Apollo started making the first non-LispM workstations, they licensed Unix as a way to get a cheap OS which they were already familiar with going fast. Unix's success in the workstation arena (not, I repeat, business use, because it was almost unknown there) was entirely built on its use in the academic world.

It was not technically superior, as the Unix Haters' Handbook shows - windowing systems were actually more common before the first generation of console-based Unix workstations hit the market, for example. It was, however, portable and cheap to license; the workstations of the late 1970s and early 1980s were hand-crafted specialty systems that cost upwards of $100k a piece, so anyone who could mass-produce a workstation for $30k was going to sell like crazy to the researchers that wanted them. Still, the main reason companies chose it - which hardly any actually did, it was as I say mainly in universities and research centers - was because their devs already knew it.

MacOS caught on because a) Apple was already popular for their earlier systems, b) they were leapfrogging other systems with having a GUI at a semi-affordable price, and c) they had better graphics than PCs did (even with the smaller, B&W screens).

MacOS caught on initially because it was technically superior (the first OS to provide a GUI).

Well, first commercially viable one, at any rate; the Lisa was too expensive, as were the Xerox Star and the various LispMs. Still, your point is valid, with one caveat: it succeeded because of what people did with that GUI, not the GUI itself. The Mac was a flop outside of a small circle of diehard Apple fans until Adobe Illustrator came along.

Mind you, the corporate polices and marketing strategies were a large factor as well. The Lisa (1983) was considerably better than the Macintosh (1984) in many ways - a faster clock speed, 1MB RAM vs 128K, built-in 10MB hard drive, multitasking OS with greyscale graphics and a better keyboard - and would probably have succeeded had Apple pitched it as an academic workstation rather than a business system. The Mac, which was pitched as an 'information appliance' and cost $2500 against the Lisa's $10k, succeeded because they sold it to the right people (casual users, graphics designers, and the anxious parents of college students, instead of business users), not because it was better.

Ironically, the first Mac with a HDD, the XL, was just a Lisa with some small modifications and a Mac Toolkit ROM. Meanwhile, Jef Raskin, the original designer of the Mac - the text-only version that never saw the light of day - left Apple and went on to design the Canon Cat as the system he intended all along before Jobs decided to muck about with the Mac project, which failed because Canon's computer division couldn't market eternal life.

Linux caught on because of the backlash against Windows and Macs, and because it built on the previous success of Unix at a time when everyone else doing Unix were busy in court slitting each others' throats.

While "backlash against Windows (and Macs)" might have influenced an insignificant number of people, for the desktop market, Linux never caught on (always was, and always will be, an irrelevant joke). For the server market, you're right (Linux built its success on backlash against the same expensive commercial Unix clones that were responsible for the success of Unix, combined with "fortunate timing" for the FreeBSD legal dispute).

I didn't even consider the Linux desktop market. While I use it myself, I don't see it as significant. When you are talking the decision to use Linux, you really are talking system admins (or their managers, but managers choose systems based on fads, rumors, and bad assumptions, primarily), and they were the ones I was talking about.

Technically superior systems such as Genera, Smalltalk-80, AmigaOS, and BeOS never got any traction, because they didn't really offer anything that people actually needed - and if the Internet has shown anything, it is that security and reliability come dead last in the list of concerns people have when choosing software, especially for those businesses where those should be the primary concern - and if you think you can cure the world of that sort of stupidity, then you are engaging in a higher-order stupidity of your own.

I have no idea what Genera is.

Genera was the Symbolics OS; most of the other LispM companies copy it pretty closely. It was rather sophisticated for the time, far more so than most Lisp environments today really. However, the LispMs were not practical commercial systems, for the most part, even those by established firms like TI and Xerox. Both Xerox (for their LispMs as well as the Smalltalk workstations) and the LispM companies like LMI and Symbolics dawdled in getting microprocessor implementations out the door because it wasn't as much fun as hand-wrapping a custom system - IRC, the only VLSI LispM chip ever actually sold was by Texas Instruments, and hit the market after interest in LispMs had died.

Smalltalk-80 is a programming language and not an OS.

It was also what most users called the OS and the user environment, because the name originally applied to the Alto's user environment, not the language or the OS. The language now called Smalltalk-72 didn't have a name of its own, nor did the original BCPL-based OS (the replacement, written in Mesa, was called Pilot OS, but that was because it was originally a separate project experimenting in distributed processing and only rolled into Smalltalk-80 when the Star was developed for sale). Even today, there are ex-PARCies who say that text-based implementations of the language without the environment, such as GNU Smalltalk, aren't really Smalltalk at all, because the language was only part of a larger system.

For home computers, Amiga (and AmigaOS) were successful originally, but Amiga (the hardware) got killed by superior (cheaper, faster) "PC hardware" and the entire company (Commodore) died (taking AmigaOS with it).

Actually, it was a flop in the US, which was the primary market they were aiming at, and mainly because they marketed the 500 as a game console and competed with the NES. In Europe, where it was marketed as a computer and was mainly going up against the Acorn, the BBC Micro, the Sinclair series, and various systems by small companies who have since vanished, it did much better, but not enough to pull CBM out of the dive it was in after Jack Tramiel left them to take over Atari, because without Tramiel, CBM couldn't market free gold.

BeOS was technically superior software running on inferior hardware until they switched to 80x86, but by then Windows9x was out and it was technically inferior software running on the same hardware.

That's not even close to correct, unless you count "vastly less expensive due to economies of scale" as technical excellence. No one, then or now, would claim that two PowerPC CPUs are less powerful than a single Pentium at a comparable clock speed, especially if they had to write system software for both. The BeBox failed for the same reason workstations in general failed: because most people needed a cheap system that could run a word processor that used a commonly shareable document format and could run Minesweeper when the boss wasn't looking more than they needed faster hardware and a better OS. It was doomed from the start, but for reasons that had absolutely nothing to do with it's technical merits - those merits never really even got tested, because no one bought the BeBox. Price, and poor management, were to blame.

As for BeOS being inferior to Windows 95 - which came out the same month as the BeBox, and three years before the stock x86 version of BeOS - I think either you never actually used BeOS, or you have forgotten a lot about Windows 95. They were, well... BeOS was better, but not by enough to get anyone's attention - as the Haiku folks could tell you today, I am sure.

Now tell me; what do you think the alternative is? Assuming you want to maximise the chance of an OS succeeding (which is always going to be extremely difficult regardless of what you do); would you:

• A) Deliberately make the OS technically inferior, because some deluded fool said "technical superiority doesn't help".
  B) Spend a decade developing an OS, and hope that the OS will eventually be so good that people assume it's just a worse than normal Linux distro (because it was easier to port everything and end users can't tell the difference).
  C) Try to make it technically superior in some way, for some purpose.

I would do what I am doing now: enjoy working on my hobby, and focusing on improving the state of the art, in the hope that I can come up with something good enough that the one or more of the mainstream systems pick the idea up (not likely, as all the things I am doing would require a radical redesign of the core system - hence the need for it to be an OS of its own - but stranger things have happened). I don't aim at getting people to use my OS - that's absolutely not going to happen except unless something unpredictable occurs, in which case the technical merits of it are irrelevant - but at getting OS developers interested in the ideas it brings to the table. So no, I don't see any reason to deliberately slack off on the design, especially since the unexpected can indeed happen and my goal is entirely predicated on technical superiority - but I have no illusions as to the idea that technical merit has any bearing on success in the marketplace, save for the negative ones of either being too poor to be even minimally acceptable, or so good that it doesn't garner enough technical support work to sustain a minimum base of experts.