> The point of a kernel is to be a hardware abstraction layer between the upper layer software and the hardware.
Not really. The point of the kernel is to allow sharing of the hardware (managing resources). Abstraction is only a side effect.
The Exokernel actually postulates that any abstraction should be *purposedly ripped out*, doing only neutral multiplexing, as abstractions are believed to degrade performance.
(Personally I'm not entirely convinced of that; my impression is rather that one needs to take care not to use *too much* abstraction, and most importantly the *right* ones.)
> Shortly into this, I had to deal with a painful and extremely nasty transition, when Apple switched from the 680x0 to the PowerPC architecture. This was necessary. The 680x0 was not a growable architecture; the PPC architecture was (and still is).
680x0 was never the problem. Everyone who has done anything at processor level will tell you that 68k was a better designed architecture than x86 from the beginning. The problem is that Motorola failed to deliver competitive processors already once, and instead of doing their homework in bringing 68k up to date, they preferred to engage in a prestigious project for a new RISC architecture developed together with IBM, who had the capabilities to do so and an interest to enter the processor market.
Now Motorola failed again, *regardless* of IBM's help. IBM OTOH, more interested in other uses of the PowerPC architecture from the beginning, and by that time it being obvious that PowerPC will never gain any real foothold in mainstream PCs (as Apple stays a niche market, MS abdannoned attempts at portability long ago, and GNU/Linux users mostly prefer mainstream x86 stuff), stepped in only reluctantly. Apple was basically left alone again. Abdannoning any further experiments with alternative architectures, and going for the mainstream at last, is really a logical consequence.
I wonder how a post containing so much misinformation can be modded "informative"...
> Quite simply, Intel no longer uses CISC. Sure the instruction set is CISC, but it's all microcode reduced to RISC instructions underneath the hood
While the internal RISC design can make up for most of the performance problems of "real" CISC processors (at a considerable overhead), it doesn't make up for any of the "ugliness" of x86's CISC instruction set.
In any case, it uses CISC very well. The internal RISC part is transparent.
> (which was done WAAAY back with the Pentium II and may have partially been implemented on the original Pentium)
It was not even partially implemented in the original Pentium. PentiumPro (First in the family of Pentium II/III) was the first Intel processor to use such a translation. Pentium was a pure CISC processor.
> MMX has been dead for a while
Not really. While the use of MMX is limited to a fairly narrow set of applications, SSE actually even introduced improvements to MMX, alongside the new SSE units. The ability to use both in parallel is really a sign that they are designed to coexist. (While using SSE in parallel to the old FPU makes little sense. In most implementations, they can't even be really executed in parallel.)
> Seriously, though, outside of the math world, you probably don't need either unless you're doing software rendering of graphics - the original reason for MMX was to speed up processing of games and video effects in software and this work is now pretty much entirely handled by the GPU.
That is completely beside the point. While Intel *marketing* was trying to sell MMX as a GPU replacement, both MMX and SSE are suitable for a very wide range of applications. Both can give a considerable performance boost in many situations, if the programmer and/or compiler is smart enough to actually use them.
> [...] and the on-chip translator between the CISC and the micro-code used to take up most of the silicon and bumps up considerably the power requirements (last time I looked).
Well, while the translation ties up a considerable part of the complexity, "most" is certainly somewhat excessive.
Interestingly, Intel's attempt to reduce the overhead by introducing an instruction cache with pretranslated instructions in the P4 design, actually made for a considerably worse performance/power consumption ratio in most applications, compared to the more traditional design used in P3 and earlier models... (The Athlon, also using a traditional design, is about as bad on the other hand...)
I wonder whether it's the implementation in P4 that is bad, or the idea is fundametally flawed. Future models are announced to depart from the P4 "Netburst" design; but will they return to the traditional approach, or will it be some optimized version of the pretranslated cache design?...
> The reason RISC was "invented" was, therefore, not as some new, revolutionary architecture, since most CPUs even then were RISC "at the core" in the same way that the IA32 is now.
That's not quite true. While RISC makes microcode unnecessary, it is really quite different in nature. If you are looking for something that resembles direct microcode programming, look for VLIW.
> RISC was invented since higher-level languages like C became more and more popular instead of writing assembly. Since almost noone was writing assembly anymore, there was little need for all the exotic instructions and addressing modes that were present in CISC computers for programmer convenience.
> Because of that, CPU designers recognized that by cutting the microcode decoding logic and in essence making the C compiler output microcode directly, they could use the freed die area to implement more cache, larger TLBs, more registers, and also tune the RISC instruction more than the CISC instructions could be.
Indeed. The funny thing is that while most geeks somehow acknowledge the advantages of RISC designs, most of them condemn Intel for going a step further in that direction with using EPIC for ia64. (EPIC being an attempt at something based on VLIW but more suitable for general purpose applications than pure VLIW.)
> Too bad. I'd like to run OS X w/out having to pay an Apple hardware premium.
As always, people are overlooking the simple reality that with all the diversity (and often actually downright bugginess) of "standard" x86 PCs, MacOS would loose a considerable amount of it's "just works" magic.
(The same thing poeple are overlooking when glorifying Apple for creating an OS that works better than other popular systems...)
> With AMD really becoming a major threat to Intel it got intel to produce higher quality products. Forcing them to rethink heat, power consumption more then just raw speed.
Did it really? My obeservations over the past 10 years (with AMD becoming more and more of a real competition) are quite to the contrary:
- The price of typical Intel workstation processors hasn't changed a bit. The only thing that changed due to the price pressure is the performance gap between the fastest and the slowest processors available at a given time becoming considerably smaller. This is a good thing resulting from the competition. (If you buy a cheap computer, you won't be that much behind as you used to be.)
- To keep it's margin in view of the above developement, Intel about quintupled the number of different processor models available at a given time, in an attempt to convince customers to still pay the considerably higher price for processors only slightly faster. The cosumer confusion is definitely a BAD thing resulting from the comeptition.
- The pressure to try being ahead resulted in all the premature products and overclocked processors, actually *causing* all the quality problems, power consumption and other flops seen in Intel products in the last years. While you get new products a few months earlier now, the competition resulted in considerably *worse* products coming from Intel. This is another BAD thing resulting from the competition.
So AMD's existance has equalled the PC market, but definitely didn't improved the quality; things are actually more confusing and troublesome for people than they used to be. I'm really not sure I like this developement.
Of course, nobody knows how Intel prices and quality would have developed *without* AMD's competition... But claims that things are better than they used to be thanks to AMD are plainly wrong.
> The goal of the whole GNU project was never to be innovative - quite the opposite. The goal was to copy Unix and all it's tools
That's wrong. The goal of the GNU project was to create a completly new OS that is, for user's convenience, backward-compatible with UNIX. Of course that implies copying the tools (though GNU introduced some innovations along the way even here); but it doesn't mean there is nothing new in GNU. On the contrary, RMS intended to add lots of new stuff. It's just the innovative parts get less recognition, as they are less familar... (Which does not apply to GNU alone but to free software in general.)
BTW, gcc was the first native C++ compiler, and also the first (only?) Objective C compiler. I'm sure there are hoards of other innovations in it if you care to take a closer look.
It's interesting to notice in this context that MS actually was always a big proponent of MDIs, and the singular exception of IE existed only because it's a Netscape ripoff...
Re:Well, let's take a look at the highest profile
on
McVoy Strikes Back
·
· Score: 1
From your comment, you seem to define something to be innovative if it's the most popular product today. People may have slightly differing ideas what innovation is about; but your's is so far off the point, it's not even funny.
Was UNIX the first time-sharing system? Was Windows the first GUI? Was Photoshop the first bitmap image editor? Was MS Office the first word processor+spreadshead+whatever? And so on. All of them are "knockoffs" of some existing products to a large amount, adding only a little new. Why would it be different with free software projects?
And how do you come about to claim there is no competition in the free software world, to drive innovation? If there are several projects doing similar things, won't the innovative ones have an advantage? Actually, there is more incentive for innovation, as that's the only way to keep an edge! In contrast to proprietary software, there is no way to fend off competition by locking the customers in.
What do you call "significant"? Of course, all modern browsers are similar in the major features; but if you look at the details, UI and all, there is lot's of innovation in Firefox -- stuff that might not be radically new, but lots of little nice solutions I've never seen in a browser before.
(Radically new concepts are usually created by researchers and other kinds of "small" inventors, and picked up for widespread use only years later; and even these are usually radically new only compared to established concepts, but adding only some little new twists over the work of other researchers they are building on.)
> In practice though, I think the only way this would really work is if it's shipped by default in Firefox.
For one, this is not generally true: In any setup where user!=admin (office, shool, inet-cafe, library, your grandma), such a plugin can be very useful even if the person *installing* it is not suspectible to fall for phishing.
More importantly, this is a *research* project; the plugin is just a testing vehicle. Once it turns out useful, browser vendors will hopefully start shipping such technology by default -- but that's very different from research work.
"The" Creative Commons License? There are a whole bunch of licenses in the Creative Commons framework; and they are quite different in the amount of freedom they offer.
maemo uses the Creative Commons Attribution license, which is free; but you always need to mention the whole name when talking about Creative Commons. The more restrictive licenses in the framework are still better than the usual proprietary licenses; but -- while they might be sufficient for typical artwork like songs or novels -- many of the Creative Commons licenses are *not* suitable for use in free software projects. For those, you need a license that offers the same amount of freedom as for the code. So be careful, and always check *which* of the Creative Commons licenses actually was used.
The Pentium Pro and all it's descendants (Pentium M being claimed to be one of them) internally use a register set large enough to run other instruction sets than x86.
However, it's not as simple as replacing the x86 instruction decoder by a PPC one. Too much of the internal units are catered to x86 needs.
Still, the idea that Intel might use it's Pentium M knowhow to create a notebook-capable variant of PowerPC is actually not that unrealistic... I doubt they would have much interest in that, though.
> Intel know a lot about 90nm technology. They have several patents that would no doubt make IBMs life a lot easier when it comes to making a G5 that works in a laptop (without sterilizing the user) and pushing the G5 beyond the 3GHz barrier
Intel's 90nm Technology actually turned out to be a big flop when it comes to pushing frequency barriers -- at least for Pentium4. Pentium M profited somewhat from 90nm; but so did PPC970 (G5)... If Intel has anything interesting to offer in terms of chip *manufacturing*, then it's the upcoming 65nm technology.
Of course, there may be other interesting things Intel has to offer... Well, let's see.
> Maybe they will do their own north bridge, in fact much of the traditional PC architecture is emulated in this device
Actually, this is mostly the southbridge. The northbridge is primarily responsible for the "modern" stuff like PCI and SDRAM and APIC and whatnot, most of which Apple uses just the same.
Actually, it does *not* depend on whether HTML4 strict or transitional is used. These only differ in what elements and attributes are allowed, but not in the definition of the allowed elements.
Your first code example is obviously invalid, in both HTML variants. However, the original example did not make it clear that the first text line directly follows <body>; depending on context, it *may* be valid. (In both transitional and strict.)
That's what I mean: The code may be valid (read: fit the DTD), but doesn't really make sense according to the standard.
You are right: Whether the code is actually valid depends on the context. It would be valid inside an element with %flow content (like <td> or <dd>); but also inside <body>, given there was some unclosed element (like <p>) before it. All the rest of the code would be really valid (though confusing); only the first text line needs some opening or enclosing tag.
No, it only makes it look good on the few "major" browsers they cared to test it on. It makes it look teribble (actually unusable in many cases) on anything else. (Including phones/PDAs, text mode browsers etc.)
> Designing for standards compliance is great, but a crappy website that loads on any standards compiant browser is a lot less useful than a beautiful, usable website that loads on the major brosers like Firefox, IE, Opera and Safari.
How about designing standards-compliant pages that are beatiful and usable, and load in all major browsers plus all the simpler ones?... (Once learned how to do it, it's much easier than presentational HTML anyways.)
In the long-term view, presentational HTML will (hopfully) drop off the part of the web caring for good looks, and browsers will subsequently start dropping workarounds and presentational tags that make the old sites look as intended. (Note: Most old sites will remain usable; only the looks will detoriate over time...)
Among other important reasons (explained by others), this is a chicken-and-egg problem: Start using XHTML today, so we can all have a better web tomorrow.
> Users love this idea, but FLOSS developers generally hate it. I develop my project for fun in my spare time; I don't want users dictating what I must do with my project.
Nobody is dictating what you must do. The nice thing about free software is that *anyone* can implement the feature.
PS. Remember that not all FLOSS developers are hobbyists...
Slashdot Mirror
> The point of a kernel is to be a hardware abstraction layer between the upper layer software and the hardware.
Not really. The point of the kernel is to allow sharing of the hardware (managing resources). Abstraction is only a side effect.
The Exokernel actually postulates that any abstraction should be *purposedly ripped out*, doing only neutral multiplexing, as abstractions are believed to degrade performance.
(Personally I'm not entirely convinced of that; my impression is rather that one needs to take care not to use *too much* abstraction, and most importantly the *right* ones.)
> Shortly into this, I had to deal with a painful and extremely nasty transition, when Apple switched from the 680x0 to the PowerPC architecture. This was necessary. The 680x0 was not a growable architecture; the PPC architecture was (and still is).
680x0 was never the problem. Everyone who has done anything at processor level will tell you that 68k was a better designed architecture than x86 from the beginning. The problem is that Motorola failed to deliver competitive processors already once, and instead of doing their homework in bringing 68k up to date, they preferred to engage in a prestigious project for a new RISC architecture developed together with IBM, who had the capabilities to do so and an interest to enter the processor market.
Now Motorola failed again, *regardless* of IBM's help. IBM OTOH, more interested in other uses of the PowerPC architecture from the beginning, and by that time it being obvious that PowerPC will never gain any real foothold in mainstream PCs (as Apple stays a niche market, MS abdannoned attempts at portability long ago, and GNU/Linux users mostly prefer mainstream x86 stuff), stepped in only reluctantly. Apple was basically left alone again. Abdannoning any further experiments with alternative architectures, and going for the mainstream at last, is really a logical consequence.
I wonder how a post containing so much misinformation can be modded "informative"...
> Quite simply, Intel no longer uses CISC. Sure the instruction set is CISC, but it's all microcode reduced to RISC instructions underneath the hood
While the internal RISC design can make up for most of the performance problems of "real" CISC processors (at a considerable overhead), it doesn't make up for any of the "ugliness" of x86's CISC instruction set.
In any case, it uses CISC very well. The internal RISC part is transparent.
> (which was done WAAAY back with the Pentium II and may have partially been implemented on the original Pentium)
It was not even partially implemented in the original Pentium. PentiumPro (First in the family of Pentium II/III) was the first Intel processor to use such a translation. Pentium was a pure CISC processor.
> MMX has been dead for a while
Not really. While the use of MMX is limited to a fairly narrow set of applications, SSE actually even introduced improvements to MMX, alongside the new SSE units. The ability to use both in parallel is really a sign that they are designed to coexist. (While using SSE in parallel to the old FPU makes little sense. In most implementations, they can't even be really executed in parallel.)
> Seriously, though, outside of the math world, you probably don't need either unless you're doing software rendering of graphics - the original reason for MMX was to speed up processing of games and video effects in software and this work is now pretty much entirely handled by the GPU.
That is completely beside the point. While Intel *marketing* was trying to sell MMX as a GPU replacement, both MMX and SSE are suitable for a very wide range of applications. Both can give a considerable performance boost in many situations, if the programmer and/or compiler is smart enough to actually use them.
> [...] and the on-chip translator between the CISC and the micro-code used to take up most of the silicon and bumps up considerably the power requirements (last time I looked).
Well, while the translation ties up a considerable part of the complexity, "most" is certainly somewhat excessive.
Interestingly, Intel's attempt to reduce the overhead by introducing an instruction cache with pretranslated instructions in the P4 design, actually made for a considerably worse performance/power consumption ratio in most applications, compared to the more traditional design used in P3 and earlier models... (The Athlon, also using a traditional design, is about as bad on the other hand...)
I wonder whether it's the implementation in P4 that is bad, or the idea is fundametally flawed. Future models are announced to depart from the P4 "Netburst" design; but will they return to the traditional approach, or will it be some optimized version of the pretranslated cache design?...
> The reason RISC was "invented" was, therefore, not as some new, revolutionary architecture, since most CPUs even then were RISC "at the core" in the same way that the IA32 is now.
That's not quite true. While RISC makes microcode unnecessary, it is really quite different in nature. If you are looking for something that resembles direct microcode programming, look for VLIW.
> RISC was invented since higher-level languages like C became more and more popular instead of writing assembly. Since almost noone was writing assembly anymore, there was little need for all the exotic instructions and addressing modes that were present in CISC computers for programmer convenience.
> Because of that, CPU designers recognized that by cutting the microcode decoding logic and in essence making the C compiler output microcode directly, they could use the freed die area to implement more cache, larger TLBs, more registers, and also tune the RISC instruction more than the CISC instructions could be.
Indeed. The funny thing is that while most geeks somehow acknowledge the advantages of RISC designs, most of them condemn Intel for going a step further in that direction with using EPIC for ia64. (EPIC being an attempt at something based on VLIW but more suitable for general purpose applications than pure VLIW.)
> Too bad. I'd like to run OS X w/out having to pay an Apple hardware premium.
As always, people are overlooking the simple reality that with all the diversity (and often actually downright bugginess) of "standard" x86 PCs, MacOS would loose a considerable amount of it's "just works" magic.
(The same thing poeple are overlooking when glorifying Apple for creating an OS that works better than other popular systems...)
> With AMD really becoming a major threat to Intel it got intel to produce higher quality products. Forcing them to rethink heat, power consumption more then just raw speed.
Did it really? My obeservations over the past 10 years (with AMD becoming more and more of a real competition) are quite to the contrary:
- The price of typical Intel workstation processors hasn't changed a bit. The only thing that changed due to the price pressure is the performance gap between the fastest and the slowest processors available at a given time becoming considerably smaller. This is a good thing resulting from the competition. (If you buy a cheap computer, you won't be that much behind as you used to be.)
- To keep it's margin in view of the above developement, Intel about quintupled the number of different processor models available at a given time, in an attempt to convince customers to still pay the considerably higher price for processors only slightly faster. The cosumer confusion is definitely a BAD thing resulting from the comeptition.
- The pressure to try being ahead resulted in all the premature products and overclocked processors, actually *causing* all the quality problems, power consumption and other flops seen in Intel products in the last years. While you get new products a few months earlier now, the competition resulted in considerably *worse* products coming from Intel. This is another BAD thing resulting from the competition.
So AMD's existance has equalled the PC market, but definitely didn't improved the quality; things are actually more confusing and troublesome for people than they used to be. I'm really not sure I like this developement.
Of course, nobody knows how Intel prices and quality would have developed *without* AMD's competition... But claims that things are better than they used to be thanks to AMD are plainly wrong.
> The goal of the whole GNU project was never to be innovative - quite the opposite. The goal was to copy Unix and all it's tools
That's wrong. The goal of the GNU project was to create a completly new OS that is, for user's convenience, backward-compatible with UNIX. Of course that implies copying the tools (though GNU introduced some innovations along the way even here); but it doesn't mean there is nothing new in GNU. On the contrary, RMS intended to add lots of new stuff. It's just the innovative parts get less recognition, as they are less familar... (Which does not apply to GNU alone but to free software in general.)
BTW, gcc was the first native C++ compiler, and also the first (only?) Objective C compiler. I'm sure there are hoards of other innovations in it if you care to take a closer look.
It's interesting to notice in this context that MS actually was always a big proponent of MDIs, and the singular exception of IE existed only because it's a Netscape ripoff...
From your comment, you seem to define something to be innovative if it's the most popular product today. People may have slightly differing ideas what innovation is about; but your's is so far off the point, it's not even funny.
Was UNIX the first time-sharing system? Was Windows the first GUI? Was Photoshop the first bitmap image editor? Was MS Office the first word processor+spreadshead+whatever? And so on. All of them are "knockoffs" of some existing products to a large amount, adding only a little new. Why would it be different with free software projects?
And how do you come about to claim there is no competition in the free software world, to drive innovation? If there are several projects doing similar things, won't the innovative ones have an advantage? Actually, there is more incentive for innovation, as that's the only way to keep an edge! In contrast to proprietary software, there is no way to fend off competition by locking the customers in.
What do you call "significant"? Of course, all modern browsers are similar in the major features; but if you look at the details, UI and all, there is lot's of innovation in Firefox -- stuff that might not be radically new, but lots of little nice solutions I've never seen in a browser before.
(Radically new concepts are usually created by researchers and other kinds of "small" inventors, and picked up for widespread use only years later; and even these are usually radically new only compared to established concepts, but adding only some little new twists over the work of other researchers they are building on.)
> In practice though, I think the only way this would really work is if it's shipped by default in Firefox.
For one, this is not generally true: In any setup where user!=admin (office, shool, inet-cafe, library, your grandma), such a plugin can be very useful even if the person *installing* it is not suspectible to fall for phishing.
More importantly, this is a *research* project; the plugin is just a testing vehicle. Once it turns out useful, browser vendors will hopefully start shipping such technology by default -- but that's very different from research work.
"The" Creative Commons License? There are a whole bunch of licenses in the Creative Commons framework; and they are quite different in the amount of freedom they offer.
maemo uses the Creative Commons Attribution license, which is free; but you always need to mention the whole name when talking about Creative Commons. The more restrictive licenses in the framework are still better than the usual proprietary licenses; but -- while they might be sufficient for typical artwork like songs or novels -- many of the Creative Commons licenses are *not* suitable for use in free software projects. For those, you need a license that offers the same amount of freedom as for the code. So be careful, and always check *which* of the Creative Commons licenses actually was used.
The Pentium Pro and all it's descendants (Pentium M being claimed to be one of them) internally use a register set large enough to run other instruction sets than x86.
However, it's not as simple as replacing the x86 instruction decoder by a PPC one. Too much of the internal units are catered to x86 needs.
Still, the idea that Intel might use it's Pentium M knowhow to create a notebook-capable variant of PowerPC is actually not that unrealistic... I doubt they would have much interest in that, though.
> Intel know a lot about 90nm technology. They have several patents that would no doubt make IBMs life a lot easier when it comes to making a G5 that works in a laptop (without sterilizing the user) and pushing the G5 beyond the 3GHz barrier
Intel's 90nm Technology actually turned out to be a big flop when it comes to pushing frequency barriers -- at least for Pentium4. Pentium M profited somewhat from 90nm; but so did PPC970 (G5)... If Intel has anything interesting to offer in terms of chip *manufacturing*, then it's the upcoming 65nm technology.
Of course, there may be other interesting things Intel has to offer... Well, let's see.
> Maybe they will do their own north bridge, in fact much of the traditional PC architecture is emulated in this device
Actually, this is mostly the southbridge. The northbridge is primarily responsible for the "modern" stuff like PCI and SDRAM and APIC and whatnot, most of which Apple uses just the same.
> Why don't you actually check with the specification before attempting to correct me?
:-)
Actually, I did check... But apparently the wrong place
Anyways, this only reinforces my original statement that the code in question is actually valid HTML...
Actually, it does *not* depend on whether HTML4 strict or transitional is used. These only differ in what elements and attributes are allowed, but not in the definition of the allowed elements.
Your first code example is obviously invalid, in both HTML variants. However, the original example did not make it clear that the first text line directly follows <body>; depending on context, it *may* be valid. (In both transitional and strict.)
That's what I mean: The code may be valid (read: fit the DTD), but doesn't really make sense according to the standard.
You are right: Whether the code is actually valid depends on the context. It would be valid inside an element with %flow content (like <td> or <dd>); but also inside <body>, given there was some unclosed element (like <p>) before it. All the rest of the code would be really valid (though confusing); only the first text line needs some opening or enclosing tag.
No, it only makes it look good on the few "major" browsers they cared to test it on. It makes it look teribble (actually unusable in many cases) on anything else. (Including phones/PDAs, text mode browsers etc.)
> Designing for standards compliance is great, but a crappy website that loads on any standards compiant browser is a lot less useful than a beautiful, usable website that loads on the major brosers like Firefox, IE, Opera and Safari.
How about designing standards-compliant pages that are beatiful and usable, and load in all major browsers plus all the simpler ones?... (Once learned how to do it, it's much easier than presentational HTML anyways.)
In the long-term view, presentational HTML will (hopfully) drop off the part of the web caring for good looks, and browsers will subsequently start dropping workarounds and presentational tags that make the old sites look as intended. (Note: Most old sites will remain usable; only the looks will detoriate over time...)
Among other important reasons (explained by others), this is a chicken-and-egg problem: Start using XHTML today, so we can all have a better web tomorrow.
How is a "light-weight" syntax-highlighting editor better than a "heavy-weight" syntax highlighting editor like emacs? (Or Vim...)
Also note that while the code doesn't follow the spirit of the HTML standard, it is actually valid. Some people consider that "correct". (Not me...)
> Users love this idea, but FLOSS developers generally hate it. I develop my project for fun in my spare time; I don't want users dictating what I must do with my project.
Nobody is dictating what you must do. The nice thing about free software is that *anyone* can implement the feature.
PS. Remember that not all FLOSS developers are hobbyists...