We don't count RHEL 5 and RHEL 6 separately, and it's likely that all organizations that went w/ RHEL 5 didn't migrate to RHEL 6. So do we then call RHEL 5 and 6 a case of fragmentation,
Well, let me ask you this: do old RHEL versions continue to get support and security fixes? Or are organizations that continue to use RHEL basically screwed?
If RHEL has continued support for old versions, then this is apples and oranges with regard to Android. New Android versions are fragmentation, while new RHEL versions are not.
The problem with Android is that a large fraction (perhaps a majority) of Android users are stuck with ancient versions of Android with no security updates and all kinds of problems, and there's absolutely nothing they can do about it short of buying a brand-new phone for $600. They're still selling Android phones with v2.2 at my local grocery store! The whole thing is a complete mess. This is not in any way like companies installing RHEL5 and then being happy with it as long as they continue to receive security updates.
Also I would point out that perhaps a "vast majority" of the linux ecosystem is where it is today thanks to paid contributors aka Red Hat, Sun, MySQL AB, Intel, Oracle, Ubuntu, Google and yes even Microsoft.
I'm going to call bullshit on this one: what did Microsoft contribute to the Linux ecosystem? I can't think of a single thing, except perhaps for the recently open-sourced.NET stuff which no one uses (yet, maybe that'll change, but for now it isn't exactly popular).
I also call bullshit on Oracle. What did they ever contribute? They bought up some other projects (MySQL and OpenOffice.org), but buying up an existing open-source product/company does not equal a contribution.
Red Hat, Sun (to an extent), Intel, Ubuntu, and Google have been contributors.
Humanity shouldn't be in the business of rewriting software hundreds of times over because they can't afford a license that would suit tailored needs. Let's write some good software to solve a problem, then move on and solve some other problem.
That sounds nice in theory, and for some things it actually does work out, but for most things, software can't just be written once and then called "done"; it has to be upgraded and maintained. And even writing it in the first place requires significant resources (peoples' time mainly).
I don't know why more open source projects don't just charge for their software. Sure this removes Freedom 0 (the freedom to run), so it's not (big-O) Open Source.
The GPL lets you charge for software. The problem is that whoever you sell it to can then distribute it willy-nilly, and who's going to pay you for a copy when they can just download it for free somewhere?
I don't think that's true, especially for business users, and especially if a purchase comes with support.
This is precisely why businesses like Red Hat charge megabucks for support and changes and give the product away for free.
Writing all your own stuff is simply more likely to have bugs, plus take a lot of time, rather than just reusing other libraries which are in use by countless other people and projects and have been vetted by them.
I'm not a big fan of the STL, however. I'd much rather use Qt's classes.
Then I don't see what you're complaining about or what your point is. Linux isn't used in places where a tiny RTOS is warranted, and vice-versa. If you don't need a general-purpose OS, and in fact it would be bad to use one, then don't use one. There is no shortage of RTOSes out there.
And you're too lazy to remember the difference between strlen and strnlen
If you're too lazy for that, you're too lazy to properly code your own version and make it as bug-free and well-tested as the standard library version. That's why we use standard libraries: there's fewer bugs when the code has been thoroughly tested by others, rather than writing your own which is bound to have new bugs.
If you have some weird special requirement, you can just write a wrapper function to handle that, and save a lot of time.
Finally, strnlen is just an example; that's really a pretty simple function, and probably only amounts to a handful of lines of C code. A better example might be any of countless Qt C++ classes. Should you write your own string class, or use an existing one from Qt or Boost? Writing your own is dumb. Same goes for writing your own XML parser.
Not every kernel needs a continuously-running userspace, particularly if it's only doing a specific job. Also, no virtual memory, and no virtual memory manager, is required - just flat memory space and jump tables to the specific routines that need to be invoked. No message-passing either. Just jump directly from one routine to the other. No multi-tasking (except for interrupts), so no multi-tasking overhead.
What you're talking about is not an OS that can be used for anything general-purpose, such as a desktop PC. It's not even an OS really, if it doesn't support multitasking. I've actually worked on an "OS" similar to this (if you can even call it that; it's really nothing more than a cooperative task scheduler), except this one had fixed-rate multitasking. This is something you'd use on a small embedded system such as with avionics, where you're controlling something in response to sensor inputs and need to keep the system extremely simple because it's safety-critical and everything must be deterministic. For things a little more complex, a commercial RTOS is normally used. These are usually much smaller and simpler than something like Linux (though RTOSes have a huge range: some are much larger and more complex, others are extremely minimalist and small).
What you're talking about, something with even less capability than MS-DOS, has no commercial use. No one uses anything like that any more; there's no reason for it since even the simplest RTOSes can very reliably handle multitasking. Can you even name any applications, or why anyone would want such a thing? If you don't need multitasking, you really don't need an OS at all, you can just run your application directly on the hardware.
Oh please. The Windows kernel isn't POSIX-compliant either, and it's huge. There's a lot more to a kernel than POSIX compatibility; that's just a standard for the interfaces, mainly the system calls.
You're completely forgetting about everything else that goes into a kernel: the virtual memory subsystem, the scheduler, networking, IPC, etc.
You sound like someone who doesn't know much about kernels. Read this.
The kernel would be very small - or non-existent, so there would be a much smaller surface to check for bugs and security holes, and much better performance
And this sounds like a claim made by the microkernel supporters. The only problem here is that microkernels have crappier performance because of the message-passing needed. As a result, no one actually uses them, except for some hybrid versions which fall short of the pure microkernel approach. And even here, there's nothing stopping microkernels from being POSIX-compliant; it's an orthogonal issue. Every kernel has to have some kind of interface with userspace, whether it's POSIX system calls or something else.
I don't even mind if distros chose not to build in modules for ancient hardware. So long as I am free to compile my own kernel who cares?
It would be idiotic for distros not to build those modules. It takes no work at all to enable everything, and the modules just get built automatically when the kernel is built. The only downside is a bit of CPU time when building the kernel (which is part of the distro's completely automated build system anyway, so they won't notice it), and a tiny bit of hard drive space. It's so insignificant that distros don't even bother putting them in a separate package to save space on the install media.
Linux always had one defining strength over Windows: It is way more modular and its parts are way more easily separated and rejoined. And now various distributions try to nix this advantage by pouring their "version" into a monolithic block that "should be good for everyone". If they feel like diversifying, you'll maybe get a "server" and a "client" distri, with the main difference being that the server distri has no GUI.
We've had this monolithic block that "should be good for everyone" for a very, very long time now: it's called "the Linux kernel". Every Linux distro, ever, has used the Linux kernel (unless you count Debian's version that uses the FreeBSD kernel). Very few people seem to have a problem with everyone using the same kernel, from big-iron servers to tiny embedded systems. And it works, very, very well.
Distributions are of course trying to take the easy way out, offering a system that will appeal to as many people as possible. Of course this lugs about a LOT of dead weight because what you need in your OS is useless to me and vv.
We've done the same thing with the kernel, since day 1. Drivers for everything are included in it. And why shouldn't they be? If you don't need drivers for something, it's not a problem as the drivers are only loaded on-demand on desktop distros. If you're worried about a few megabytes of hard drive space in the age of 1TB+ drives, you have some seriously skewed priorities. And on custom embedded systems where the drivers are compiled in (or included on the initrd), the extra drivers take no space at all since they aren't shipped with the system if they aren't used.
All this "dead weight" is actually useful to people; as long as it isn't taking up system memory and CPU cycles, who cares?
Because then you'll just be reinventing the wheel, badly.
Every modern OS kernel basically does the exact same thing. MacOS X's kernel is POSIX compatible, even though it's rather different internally than Linux, and does multi-processing the same way. Window's kernel is really based on VMS, is not POSIX compatible (there are some extensions somewhere for the OS to emulate it, but that's different), but it still basically does the exact same thing: multi-processing with virtual memory.
The big debate these days in kernels is just over whether we should have microkernels or monolithic kernels. Mac's and Windows' kernels are both hybrids.
If you really think you have a better idea for how an OS should work, let's hear it. Lots of other really smart OS experts out there have come up with various ideas, but at their core they're really mostly the same, except for the debate over microkernel vs. monolithic.
A C call to "strnlen" is required to make your program run, but if you wrote your own version of that standard library function, which did the exact same thing, *that* is useless. A program which simply calls that function uses the functionality without actually making it part of the program (the source part), simply by including a library and calling it. That function could be considered "boilerplate" if you made your own version and included it in every program you wrote, instead of using the library; it's necessary, but it's wasting space and should be replaced with the library version.
All that error-checking is necessary too, but by now, shouldn't we have high-level languages where most of that stuff is handled automatically?
Since when have coders started subscribing to wishful thinking where you just wave your hands and the computer does all the hard stuff?
Since they stopped writing everything in assembly language, that's when. That's why we invented standard libraries and high-level languages: so we wouldn't have to reinvent the wheel constantly. Do you write all your programs in assembly, doing polymorphism by manually setting up virtual function tables and jumping to them with jump instructions? Or do you program in an OO language like C++ and just use its built-in polymorphism features?
This has no relationship to assembly at all. If you were to rewrite a Java program in assembly, you'd have to replicate *everything* the language does yourself. You'd have even more boilerplate.
The whole point of a high-level language is to avoid having to redo the same work for every project, or having to redo something that someone else could have done for you, and to express what you want the computer to do more concisely. Instead of, for instance, looking up the memory location of an array member and incrementing it, you just type "myarray[i]++". Doing that in assembly would take a lot of typing.
The fact that Java requires so much boilerplate really defeats the purpose of using a high-level language. You shouldn't have to do all that stuff; it should be built-in to either the language (like polymorphism is built into OO languages like C++, whereas in C you end up manually setting up function tables), or built into the standard libraries, so that you don't need to do much to make use of that work.
Requiring developers to add a lot of boilerplate makes for *worse* readability and maintainability, because that's more work for them to do, and more things that can go wrong.
Who? It's not just houses; no one's going to want to have an office park next to one, or just about anything else.
I suppose a few things might work: a junkyard, a sewage treatment plant, etc. Basically things that are such eye-sores (or smell so bad) that no one wants to be near them either, and the people who own or work at them just aren't numerous or powerful enough to cause problems if they refuse to go to work there.
What the hell are you talking about? You think buses are more optimal? Which only go along linear, fixed routes and stop at every stop, and end up taking forever to get anywhere?
Cars are more energy efficient than buses. Many studies have proven this. And taking a car anywhere is always faster than taking a bus, because 1) it doesn't take you door-to-door, 2) it frequently takes an indirect route (possibly requiring a transfer), and 3) it stops too frequently.
Your article doesn't even make sense. What is the primary transit method in this city I've never even heard of (Masdar)? And what exactly is your proposal for a transit system? If your answer is subways, you're a moron because PRT isn't meant to be a primary system for ultradense cities like downtown NYC or London, but for less-dense areas which are currently dominated by cars. If your answer is buses, you're a moron as I pointed out above. Buses do not work. Light rail doesn't work either because it has the same problems as buses, except it's even worse because the construction expense is astronomical and you can't easily modify the route as buses can.
Im not sure what you are getting at, that because I dont mind living 5 miles down the road i should live closer?
What I'm getting at is: how many people live right next to such a plant?
Generally, you don't see subdivisions and shopping centers within visual distance of them.
Should there be a nuke plant in downtown Manhattan? probably not, but having one along the hudson 30 miles away hasnt hurt anyone and its been running for 40 something years
30 miles away really isn't quite within the metro area.
I used to live in Phoenix. Palo Verde supplies a lot of power to the Phoenix metro area, but Palo Verde itself is out in the middle of nowhere. It's probably 30-50 miles away (can't remember exactly how far, and depends on how you measure), but it's certainly not right there amid all the development.
So, I simply tell my honest experience with something, and some asshole tells me I'm wrong and to fuck off, and *I'm* the one with the problem? Fuck you.
Ok, obviously I should have said "shouldn't" instead of "can't". Just look at Fukushima for a great example of how and where not to build a nuclear plant.
Well why don't you live right next door to it then?
What kind of metro area has a power plant with a 5-mile-radius zone around it with nothing in it? I'm talking about putting power plants right in metro areas, not 30 miles nearby, which is what everyone else here seems to be talking about.
Wow, are you really that stupid? SkyTran already exists; they've already built prototypes, and it uses technology even less complicated than self-driving cars.
I guess you were one of those people who said the internet would never amount to anything too.
Slashdot Mirror
We don't count RHEL 5 and RHEL 6 separately, and it's likely that all organizations that went w/ RHEL 5 didn't migrate to RHEL 6. So do we then call RHEL 5 and 6 a case of fragmentation,
Well, let me ask you this: do old RHEL versions continue to get support and security fixes? Or are organizations that continue to use RHEL basically screwed?
If RHEL has continued support for old versions, then this is apples and oranges with regard to Android. New Android versions are fragmentation, while new RHEL versions are not.
The problem with Android is that a large fraction (perhaps a majority) of Android users are stuck with ancient versions of Android with no security updates and all kinds of problems, and there's absolutely nothing they can do about it short of buying a brand-new phone for $600. They're still selling Android phones with v2.2 at my local grocery store! The whole thing is a complete mess. This is not in any way like companies installing RHEL5 and then being happy with it as long as they continue to receive security updates.
Also I would point out that perhaps a "vast majority" of the linux ecosystem is where it is today thanks to paid contributors aka Red Hat, Sun, MySQL AB, Intel, Oracle, Ubuntu, Google and yes even Microsoft.
I'm going to call bullshit on this one: what did Microsoft contribute to the Linux ecosystem? I can't think of a single thing, except perhaps for the recently open-sourced .NET stuff which no one uses (yet, maybe that'll change, but for now it isn't exactly popular).
I also call bullshit on Oracle. What did they ever contribute? They bought up some other projects (MySQL and OpenOffice.org), but buying up an existing open-source product/company does not equal a contribution.
Red Hat, Sun (to an extent), Intel, Ubuntu, and Google have been contributors.
Humanity shouldn't be in the business of rewriting software hundreds of times over because they can't afford a license that would suit tailored needs. Let's write some good software to solve a problem, then move on and solve some other problem.
That sounds nice in theory, and for some things it actually does work out, but for most things, software can't just be written once and then called "done"; it has to be upgraded and maintained. And even writing it in the first place requires significant resources (peoples' time mainly).
I don't know why more open source projects don't just charge for their software. Sure this removes Freedom 0 (the freedom to run), so it's not (big-O) Open Source.
The GPL lets you charge for software. The problem is that whoever you sell it to can then distribute it willy-nilly, and who's going to pay you for a copy when they can just download it for free somewhere?
I don't think that's true, especially for business users, and especially if a purchase comes with support.
This is precisely why businesses like Red Hat charge megabucks for support and changes and give the product away for free.
Writing all your own stuff is simply more likely to have bugs, plus take a lot of time, rather than just reusing other libraries which are in use by countless other people and projects and have been vetted by them.
I'm not a big fan of the STL, however. I'd much rather use Qt's classes.
Then I don't see what you're complaining about or what your point is. Linux isn't used in places where a tiny RTOS is warranted, and vice-versa. If you don't need a general-purpose OS, and in fact it would be bad to use one, then don't use one. There is no shortage of RTOSes out there.
And you're too lazy to remember the difference between strlen and strnlen
If you're too lazy for that, you're too lazy to properly code your own version and make it as bug-free and well-tested as the standard library version. That's why we use standard libraries: there's fewer bugs when the code has been thoroughly tested by others, rather than writing your own which is bound to have new bugs.
If you have some weird special requirement, you can just write a wrapper function to handle that, and save a lot of time.
Finally, strnlen is just an example; that's really a pretty simple function, and probably only amounts to a handful of lines of C code. A better example might be any of countless Qt C++ classes. Should you write your own string class, or use an existing one from Qt or Boost? Writing your own is dumb. Same goes for writing your own XML parser.
Not every kernel needs a continuously-running userspace, particularly if it's only doing a specific job. Also, no virtual memory, and no virtual memory manager, is required - just flat memory space and jump tables to the specific routines that need to be invoked. No message-passing either. Just jump directly from one routine to the other. No multi-tasking (except for interrupts), so no multi-tasking overhead.
What you're talking about is not an OS that can be used for anything general-purpose, such as a desktop PC. It's not even an OS really, if it doesn't support multitasking. I've actually worked on an "OS" similar to this (if you can even call it that; it's really nothing more than a cooperative task scheduler), except this one had fixed-rate multitasking. This is something you'd use on a small embedded system such as with avionics, where you're controlling something in response to sensor inputs and need to keep the system extremely simple because it's safety-critical and everything must be deterministic. For things a little more complex, a commercial RTOS is normally used. These are usually much smaller and simpler than something like Linux (though RTOSes have a huge range: some are much larger and more complex, others are extremely minimalist and small).
What you're talking about, something with even less capability than MS-DOS, has no commercial use. No one uses anything like that any more; there's no reason for it since even the simplest RTOSes can very reliably handle multitasking. Can you even name any applications, or why anyone would want such a thing? If you don't need multitasking, you really don't need an OS at all, you can just run your application directly on the hardware.
Oh please. The Windows kernel isn't POSIX-compliant either, and it's huge. There's a lot more to a kernel than POSIX compatibility; that's just a standard for the interfaces, mainly the system calls.
You're completely forgetting about everything else that goes into a kernel: the virtual memory subsystem, the scheduler, networking, IPC, etc.
You sound like someone who doesn't know much about kernels. Read this.
The kernel would be very small - or non-existent, so there would be a much smaller surface to check for bugs and security holes, and much better performance
And this sounds like a claim made by the microkernel supporters. The only problem here is that microkernels have crappier performance because of the message-passing needed. As a result, no one actually uses them, except for some hybrid versions which fall short of the pure microkernel approach. And even here, there's nothing stopping microkernels from being POSIX-compliant; it's an orthogonal issue. Every kernel has to have some kind of interface with userspace, whether it's POSIX system calls or something else.
I don't even mind if distros chose not to build in modules for ancient hardware. So long as I am free to compile my own kernel who cares?
It would be idiotic for distros not to build those modules. It takes no work at all to enable everything, and the modules just get built automatically when the kernel is built. The only downside is a bit of CPU time when building the kernel (which is part of the distro's completely automated build system anyway, so they won't notice it), and a tiny bit of hard drive space. It's so insignificant that distros don't even bother putting them in a separate package to save space on the install media.
Do you have any real examples for this quirky hardware which you claim actually affects peoples' systems?
Linux always had one defining strength over Windows: It is way more modular and its parts are way more easily separated and rejoined. And now various distributions try to nix this advantage by pouring their "version" into a monolithic block that "should be good for everyone". If they feel like diversifying, you'll maybe get a "server" and a "client" distri, with the main difference being that the server distri has no GUI.
We've had this monolithic block that "should be good for everyone" for a very, very long time now: it's called "the Linux kernel". Every Linux distro, ever, has used the Linux kernel (unless you count Debian's version that uses the FreeBSD kernel). Very few people seem to have a problem with everyone using the same kernel, from big-iron servers to tiny embedded systems. And it works, very, very well.
Distributions are of course trying to take the easy way out, offering a system that will appeal to as many people as possible. Of course this lugs about a LOT of dead weight because what you need in your OS is useless to me and vv.
We've done the same thing with the kernel, since day 1. Drivers for everything are included in it. And why shouldn't they be? If you don't need drivers for something, it's not a problem as the drivers are only loaded on-demand on desktop distros. If you're worried about a few megabytes of hard drive space in the age of 1TB+ drives, you have some seriously skewed priorities. And on custom embedded systems where the drivers are compiled in (or included on the initrd), the extra drivers take no space at all since they aren't shipped with the system if they aren't used.
All this "dead weight" is actually useful to people; as long as it isn't taking up system memory and CPU cycles, who cares?
Because then you'll just be reinventing the wheel, badly.
Every modern OS kernel basically does the exact same thing. MacOS X's kernel is POSIX compatible, even though it's rather different internally than Linux, and does multi-processing the same way. Window's kernel is really based on VMS, is not POSIX compatible (there are some extensions somewhere for the OS to emulate it, but that's different), but it still basically does the exact same thing: multi-processing with virtual memory.
The big debate these days in kernels is just over whether we should have microkernels or monolithic kernels. Mac's and Windows' kernels are both hybrids.
If you really think you have a better idea for how an OS should work, let's hear it. Lots of other really smart OS experts out there have come up with various ideas, but at their core they're really mostly the same, except for the debate over microkernel vs. monolithic.
A C call to "strnlen" is required to make your program run, but if you wrote your own version of that standard library function, which did the exact same thing, *that* is useless. A program which simply calls that function uses the functionality without actually making it part of the program (the source part), simply by including a library and calling it. That function could be considered "boilerplate" if you made your own version and included it in every program you wrote, instead of using the library; it's necessary, but it's wasting space and should be replaced with the library version.
All that error-checking is necessary too, but by now, shouldn't we have high-level languages where most of that stuff is handled automatically?
Since when have coders started subscribing to wishful thinking where you just wave your hands and the computer does all the hard stuff?
Since they stopped writing everything in assembly language, that's when. That's why we invented standard libraries and high-level languages: so we wouldn't have to reinvent the wheel constantly. Do you write all your programs in assembly, doing polymorphism by manually setting up virtual function tables and jumping to them with jump instructions? Or do you program in an OO language like C++ and just use its built-in polymorphism features?
This has no relationship to assembly at all. If you were to rewrite a Java program in assembly, you'd have to replicate *everything* the language does yourself. You'd have even more boilerplate.
The whole point of a high-level language is to avoid having to redo the same work for every project, or having to redo something that someone else could have done for you, and to express what you want the computer to do more concisely. Instead of, for instance, looking up the memory location of an array member and incrementing it, you just type "myarray[i]++". Doing that in assembly would take a lot of typing.
The fact that Java requires so much boilerplate really defeats the purpose of using a high-level language. You shouldn't have to do all that stuff; it should be built-in to either the language (like polymorphism is built into OO languages like C++, whereas in C you end up manually setting up function tables), or built into the standard libraries, so that you don't need to do much to make use of that work.
Requiring developers to add a lot of boilerplate makes for *worse* readability and maintainability, because that's more work for them to do, and more things that can go wrong.
You just put it next to someone else metro area
Who? It's not just houses; no one's going to want to have an office park next to one, or just about anything else.
I suppose a few things might work: a junkyard, a sewage treatment plant, etc. Basically things that are such eye-sores (or smell so bad) that no one wants to be near them either, and the people who own or work at them just aren't numerous or powerful enough to cause problems if they refuse to go to work there.
Ok, show me some nuclear plants with residential subdivisions packed within a 5-mile radius and I'll believe you that so many people don't care.
What the hell are you talking about? You think buses are more optimal? Which only go along linear, fixed routes and stop at every stop, and end up taking forever to get anywhere?
Cars are more energy efficient than buses. Many studies have proven this. And taking a car anywhere is always faster than taking a bus, because 1) it doesn't take you door-to-door, 2) it frequently takes an indirect route (possibly requiring a transfer), and 3) it stops too frequently.
Your article doesn't even make sense. What is the primary transit method in this city I've never even heard of (Masdar)? And what exactly is your proposal for a transit system? If your answer is subways, you're a moron because PRT isn't meant to be a primary system for ultradense cities like downtown NYC or London, but for less-dense areas which are currently dominated by cars. If your answer is buses, you're a moron as I pointed out above. Buses do not work. Light rail doesn't work either because it has the same problems as buses, except it's even worse because the construction expense is astronomical and you can't easily modify the route as buses can.
Im not sure what you are getting at, that because I dont mind living 5 miles down the road i should live closer?
What I'm getting at is: how many people live right next to such a plant?
Generally, you don't see subdivisions and shopping centers within visual distance of them.
Should there be a nuke plant in downtown Manhattan? probably not, but having one along the hudson 30 miles away hasnt hurt anyone and its been running for 40 something years
30 miles away really isn't quite within the metro area.
I used to live in Phoenix. Palo Verde supplies a lot of power to the Phoenix metro area, but Palo Verde itself is out in the middle of nowhere. It's probably 30-50 miles away (can't remember exactly how far, and depends on how you measure), but it's certainly not right there amid all the development.
So, I simply tell my honest experience with something, and some asshole tells me I'm wrong and to fuck off, and *I'm* the one with the problem? Fuck you.
Ok, obviously I should have said "shouldn't" instead of "can't". Just look at Fukushima for a great example of how and where not to build a nuclear plant.
Well why don't you live right next door to it then?
What kind of metro area has a power plant with a 5-mile-radius zone around it with nothing in it? I'm talking about putting power plants right in metro areas, not 30 miles nearby, which is what everyone else here seems to be talking about.
Wow, are you really that stupid? SkyTran already exists; they've already built prototypes, and it uses technology even less complicated than self-driving cars.
I guess you were one of those people who said the internet would never amount to anything too.
You do? You live right next door to one? You can see the cooling towers from your front door?
That must have been some really cheap real estate.
My description is 100% correct for northern New Jersey. If you don't like it, you can suck my dick.
Fuck off with *your* ignorant opinion, asshole.