A) Users shouldn't have to know how to burn an OS disk.
I think burning a disk, whether it is an OS disk or not, should be a trivial drag&drop task. But I agree that it should not be necessary for installation, in an ideal world.
B) They shouldn't have to know how to boot from one (sorry, but it's true even if Microsoft uses it's advantage to force itself to be preinstalled).
In an ideal world, I agree again. But its quite hard to create an installer that runs directly from Windows (though some distributions showed it was feasible). Maybe you are right and this is an important direction to persue.
C) Users should *NEVER* have cause to edit a file by hand.
In an ideal world, that is true. But GUI tools to edit everything do not exist. Not in the Linux world, and not in Microsoft world. That's why users still (rarely) have to edit the registry, and (rarely) have to edit config files. There are fewer and fewer cases of this though, and usually only niche-users have to do it, and even then, there are very verbose howto's that explain, almost at the keystroke level, what to do and how to do it.
D) Drivers should be supported with a stable API.
I am not sure how this is relevant, but I believe that the tradeoff between functionality and API stability is already at a reasonable place.
E) A DE should be seamless, simple, clear and UI functionality should be consistent across applications.
KDE has reached a far further point than Windows at this point. KDE applications are far more consistent than Windows equivalents.
F) Any common task should be achievable with a clear and simple GUI utility.
Already there. Or do you have some counter-examples?
I like KDE personally, a lot. But seamless, simple and clear it is not. I'd call it simplish and somewhat clear. But to be seamless would require reaching well beyond KDE's scope. A Linux desktop if made up of a number of layers, a number of programs each of which adheres to its programmer or programmers own ideas. There is no broader unified vision.
I disagree. There's a "broader vision", and that's the job of the integrator: The "distribution". They send patches to all layers upstream. They write KDE/Gnome GUI utils where they are lacking, to manage their distribution's lower layers. They request, patch or fix the lower layers so they play nice with the requirements of the higher layers.
Distributions stand between the thousands upon thousands of developers as one integrating entity so that the user only sees one centralized entity. He only has to trust one entity with his application downloads (as opposed to each and every installation site he downloads from). He only has one entity to which it has to turn in order to file bugs and requests, in a familiar fashion. Consistency is reached across different developers and environments.
That's why distributions are so important, and I am glad that the development model evolved such that they exist - though it may have been an inevitable consequence in any case:-)
If you knew anything about what you're trying to talk about, you'd know that multi-threading is used for these kinds of situations, as well as in GUI programming. And not just "when SMP scalability is an issue". This has nothing to so with the Win32 API design, it just was tackling a very specific problem. It doesn't mean that the Win32 API "requires threading", or that MS's engineers are incompetent, and that they used an additional thread unnecessarily here. Threads can be trivial, and this is I would say actually the most trivial case of their use. It's to their credit that they involved threads here (and might actually have been the only way), and it's to your ignorance that you don't understand any of this and got everything wrong about it.
Threads are indeed used in GUI's and other places. But they are used because the software engineers are incompetent. There are far simpler approaches than threading, but since they look more complicated on surface-level, the incompetent engineers use threads instead.
The flaw was in doing the WaitForSingleObject() in the DLL's detach process function without specifying a timeout value. Even if you have no reason to think that the thread won't be there to signal you eventually, sometimes the unthinkable occurs.
I admit I have not really dug deep into the flaw, but I dug deep enough to realize that threads were an unnecessary complication, and was not surprised to learn that their use was a factor in the problem.
The Windows installer also talks about partitions. It asks you to [c]reate, [r]emove, or format a partition.
It actually offers more options with more terminology than the Ubuntu/Kubuntu installer.
The Ubuntu installer offers you install options: "Simple - use free space" "Simple - overwrite whole disk" "Advanced - Setup your own partition table"
Ofcourse most users can choose one of the simple options. The advanced one has a nice GUI to resize partitions and basically do everything from a GUI. In Windows its a bit more complicated than that, as explained above.
So nice try, but even partition-wise, Ubuntu/Kubuntu have easier installers.
Its not 1998. Try Ubuntu/Kubuntu out. You don't need to know anything to get those running. Their installation is far easier than the Windows installation, and most of the common things people do "just work". Those rare occasions that don't "just work" have very simple step-by-step howto's all over the place.
They don't strip away your choices, but they sure dumb them down so unless you really want to - you are not aware of having to make any decision.
Linux is ready for the desktop - and it is already in many desktops. Many people don't use it not because its not ready, but because they don't know how to burn a CD, how to boot from it, what "installing an OS" means, and because they are afraid. Not because Linux "is not ready" and any of that nonsense.
The web architecture is one of the most terrible accidents of computing history, and I truly hope we finish this terrible software design phase soon. I am pretty sure that we'll all look back and see how terrible this all was, but as of now, only a few of us seem to notice how terrible the web really is.
Reasons for why the web is terrible (and thus no web apps can be contenders for "the best apps ever"):
It makes the communication medium a decisive factor in the application design. Whether my application runs the logic locally or remotely, and the exact medium used to synchronize its components should be as transparent as possible. But the web architecture means that if I want an app to run locally, or over the web, I have to rewrite the whole thing, with different languages, tools and protocols!
It encourages and often forces things to run in the "wrong" side (not where it would minimize communications) because to move a code component from to this side or the other requires rewriting it in a different languages (such as Javascript on one side, or whatever is used on the server-side). This results in slow and less responsive applications than local ones.
The platform has no idea what you're doing, when writing a web app. You are not communicating your intent, but exactly how to get bits and pieces of CSS, HTML and XML over the wire. This makes implicit caching and other platform-accelerations more difficult and even impossible. That is another reason why web apps are less responsive and slower than local ones.
Forms and web widgets are limited and crippled versions of the local ones, and far harder to use and apply than the local equivalents.
There are many more reasons for why the web sucks. But the main idea is that instead of extending local GUIs to reasonably and securely run over a network, they took static data formatters that can read data from a network and extended them to support rich GUIs and scripting. This is simply wrong, and I really hope that more people see how wrong this is as soon as possible.
There's a reason all the important open source APIs (gtk, glibc, alsa, X etc) have "gone stable" in the past 5 years, and it's simply a better approach.
But they only have to maintain source-level compatibility. Microsoft has to maintain binary-level compatibility.
Also, when specific things are extremely and seriously broken, compatibility can be dropped altogether, and some buggy programs broken. Microsoft cannot afford to break buggy programs, even if those are few and far between - nobody can fix them.
Multi-threading is never trivial.
Using a multi-threaded approach here, when SMP scalability is not an issue, suggests that either their API design is crap, and requires threading, or that their engineers are incompetent and use threads unnecessarily. Threads are never trivial - but what they were trying to do was quite trivial. Its their fault they involved threads in there.
The complexity of Linux, Windows and MacOS X are all much the same
Compare the complexity of APIs. fork/exec vs CreateProcess. open vs CreateFile. To use either of the Windows ones you have to call multiple APIs with multiple complicated structures documented upon pages and pages of explanations you must do more than skim through.
Windows may have similar complexity in some subsets of its APIs, but the Windows APIs I had the misfortune to use were insanely complicated unnecessarily.
Microsoft, in its stupidity and/or attempt to complicate their system so that potential compatibility is more difficult, duplicated the functionality of the "file system" with the registry. That makes registry keys such as CLSID's filenames too. The grandparent was right in calling them magic file names.
Its only useful in a closed-source world where you cannot modify programs to suit the new API's.
It accumulates complexity over time.
The result is that even Microsoft can't get reasonably trivial things right. Not to mention almost all Windows software code being highly complicated compared to equivalent code on other systems.
For every sort operation one would have to write a comparison function to decide which object should come before the other.
There is already a comparison function written for each type of object (especially ints and strings, the only objects sort can really compare).
Piping objects is a super-set of the power of piping textual strings, as a sibling poster mentioned: You can always convert objects to strings, but not vice versa.
A powershell equivalent (with my own invented syntax): du -x / | sort
Ofcourse since "du" outputs numbers, sort will already compare them properly, whereas with text-strings, you have "weak typing" and need to re-specify how to correctly interpret the data (sort -n).
Another advantage of having data in text format is that you can test it using the keyboard and screen very easily, no need to run a special debugger.
Objects can represent themselves in any meaningful way you want. As text, too. So you don't need a debugger either.
Debugging and generally programming the shell would become easier as you will be communicating your intent, rather than using ad-hoc string encoding/recoding techniques to get the data through the tools.
An object powershell is more powerful than a shell, kind of like Python is more powerful than bash, except that unlike Python, its syntax is designed to be easy for one-liners.
I think that's what people are saying here: "We don't like it, so we don't use it." I guess they are saying this as they are hoping that the OpenBSD folks realize that their user base is small enough as it is to use such user-alienating tactics.
As some people here have mentioned, web pages can get into "Google hell" by being referred to from unrelated sites. Web pages can get a spam penalty for sitting next to a viagra site.
So, can't I just buy links for my competitor's website, on a site that links to various spam/viagra sites?
If its so easy to crash into Google Hell and so hard to get out, isn't it too abuseable?
The worst part of it is that the driver, being GPL, could be included legally without the autor's consent however, this would risk alienating this valuable developper.
You are forgetting the distributions here. They can insert whatever patches they want into the kernels they use.
Their role here, is to integrate GPL software from various vendors. And there are many distributions, I doubt all of them do all the worrying about alienating a kernel developer. Once one distribution gets it to "just work", pressure is put on the rest to do the same.
I think the "mainline kernel" (as distributed by Linus Torvalds) is less important now, as the main channel of distribution of kernels (and most other packages) are the distributions and not the authors. This is great, as one coordinating entity can make all the required changes and integrations to GPL'd software to make it work together.
It may be that most users will download it directly because it is free as in beer. But they are also directly downloading it because of its functionality.
And its functionality was made possible because it is Free as in speech and for no other reason.
And if their functionality suddenly breaks because a closed-source distributor decided to give up their support for Linux - or nVidia stops maintaining their drivers, they will stop using Linux just the same.
So Free Speech is an important aspect in building the functionality and maintaining a system that will work independently of business interests. Pushing for Free as in Speech software in Linux should not be underrated, even if you come from a functional, rather than a philosophical, standpoint.
When you enable Changes' tracking and have lots of "advanced features" (tables, images, etc) in a large document -- you definitely get some keystroke lag, even on pretty modern machines.
I used to turn off changes' tracking so Word would not be so slow on my larger documents.
I believe it has just recently made it clear that it surpasses the quality of Windows not just on the server, but on the desktop as well (2 Years ago it was not clear, and for many reasons leaning towards Windows as better).
I believe that in the future (perhaps 5 years or more), your point will be true. However, to say that there is more software written that works with Debian than with Windows (based on a "package count") is indeed bogus.
There is probably a lot more written for Windows, maybe even more functionality available - though to legally access it, a user would have to pay thousands of different entities insane amounts of money. There are a lot of invisible software packages for niche users that you never hear about, unless you work in a geological surveying company, or whatever.
Ubuntu is gaining critical mass, and its development seems to be accelerating every year. It truly seems that Microsoft is not keeping up the pace, and in a few years, I believe and hope that even ordinary users will be convinced that GNU Linux desktops are overwhelmingly better. Silly fronts like "beryl", I believe, are actually the weapon that works best against Microsoft users.
1) You can't just type "office" anywhere in Linux and get the same same result either, you've got to type it a certian way and in specific places to get a list of apps to instal. In other words, you still have to go through steps. They might be different steps than you take in windows, but steps none the less. Don't front. And you know, if the google search field counts, you can do what you suggest on ANY OS that supports a browser.
You have to type it in a specific text box - that of your package manager. And then, the various alternatives are 1 click away. That is never true in Windows, it is much more difficult and involves far more to find, download and install from the web. And far worse, it involves far worse trust in untraceable entities! My packages are signed by the maintainers who registered themselves and are trackable.
2) Anyone who says (or implies) that you can't legally download software or updates using windows is just plain ignorant.
I didn't say you couldn't legally download, I said you couldn't download the updates for your entire software repository (including not just Microsoft software, but also your games, your Instant Messangers, Photo editors, etc) from one central location, which remains true.
3) You can't avoid burning fuel to bring those bits to your desktop, unless you've suddenly discovered a new way of powering the world that you also installed into every power generation station on the planet while no one was looking... We generate power by (in what, say 80% of cases) by using some sort of toxic fuel... Bits don't move themselves. Their carbon footprint might be smaller than your car's, but it's still there.
Talk about nitpicking! Yes, some fuel is burnt (unless wind or solar power is powering those routers, ofcourse), but to compare that to the fuel burnt to power the car to and from the store to carry the bits is absurd.
You can't just type in office in your package manager window, and click open office for it to be downloaded and installed for you. As well as showing you one-click-away offices right next to it, too.
In Windows, you have to find the office suite in various web sites, and click quite a few more than one click to actually download it, after which you have to click more to run the untrusted executable (In Linux, my downloads are signed by a trusted repository and trackable entities).
I did not say you couldn't download it - I said you couldn't download it and install it as easily as in Linux.
never trust the input, no matter where (you think) it comes from.
That's a little exaggerated. One internal function calling another can "trust" the neighboring function, as long as it is used internally and closely. Allowing this encourages the use of tiny trivial functions that can be reviewed.
I've actually seen people write every function with a large documentary skeleton, either asserting on every condition of every argument, or checking them with error codes. That's great for inter-module API functions. It is. It is even better than the other extreme (The Microsoft-ish trust-all).
But using such checks for internal functions results in:
Code bloat.
Discourages the creation of functions, therefore people don't divide to functions as much as they should, making functions large and unreviewable.
Repetative assertions and incorrect documentation thrown all over the place.
So I would say: Never trust input that comes from external sources. And now the problem becomes defining external. But input from a file (a.DOC) is definitely external.
Hahahaha! That is so early 90's! Hello?? We have the internet! Software can be downloaded!
In Windows, I can't just type in "office", click the resulting "kde office" and "open office" programs, and have them automatically downloaded for me, without fuel being burnt to get the bits from there to my computer. Amazing!
Also, I can just type in almost anything I may want my computer to do - and behold, one of more than 10,000 programs shows up which can be installed with a single click!
Oh wait, there's more. When I play a movie in full-screen, a bunch of "Would you like to update me?" dialogs of various programs don't jump up at me! In fact, *all* (and that means all software you have) updating is done from a central location - by clicking the update icon.
Oh, Windows doesn't have that? Pitty, maybe I should stick to Linux!
By the age kids can play these games at all, they are already exposed to advertisements, to the internet and to modern television.
Are there any innocent kids left in the western world?
I am not saying this is necessarily a bad thing, but I think that kids born in the 90's are not nearly as innocent as those before the 80's, and the whole "childhood" concept has changed considerably.
Slashdot Mirror
I think burning a disk, whether it is an OS disk or not, should be a trivial drag&drop task. But I agree that it should not be necessary for installation, in an ideal world.In an ideal world, I agree again. But its quite hard to create an installer that runs directly from Windows (though some distributions showed it was feasible). Maybe you are right and this is an important direction to persue.
In an ideal world, that is true. But GUI tools to edit everything do not exist. Not in the Linux world, and not in Microsoft world. That's why users still (rarely) have to edit the registry, and (rarely) have to edit config files.
There are fewer and fewer cases of this though, and usually only niche-users have to do it, and even then, there are very verbose howto's that explain, almost at the keystroke level, what to do and how to do it.
I am not sure how this is relevant, but I believe that the tradeoff between functionality and API stability is already at a reasonable place.
KDE has reached a far further point than Windows at this point. KDE applications are far more consistent than Windows equivalents.
Already there. Or do you have some counter-examples?
I disagree. There's a "broader vision", and that's the job of the integrator: The "distribution". They send patches to all layers upstream. They write KDE/Gnome GUI utils where they are lacking, to manage their distribution's lower layers. They request, patch or fix the lower layers so they play nice with the requirements of the higher layers.
Distributions stand between the thousands upon thousands of developers as one integrating entity so that the user only sees one centralized entity.
He only has to trust one entity with his application downloads (as opposed to each and every installation site he downloads from).
He only has one entity to which it has to turn in order to file bugs and requests, in a familiar fashion.
Consistency is reached across different developers and environments.
That's why distributions are so important, and I am glad that the development model evolved such that they exist - though it may have been an inevitable consequence in any case
Threads are indeed used in GUI's and other places. But they are used because the software engineers are incompetent. There are far simpler approaches than threading, but since they look more complicated on surface-level, the incompetent engineers use threads instead.
I admit I have not really dug deep into the flaw, but I dug deep enough to realize that threads were an unnecessary complication, and was not surprised to learn that their use was a factor in the problem.
The Windows installer also talks about partitions. It asks you to [c]reate, [r]emove, or format a partition.
It actually offers more options with more terminology than the Ubuntu/Kubuntu installer.
The Ubuntu installer offers you install options:
"Simple - use free space"
"Simple - overwrite whole disk"
"Advanced - Setup your own partition table"
Ofcourse most users can choose one of the simple options. The advanced one has a nice GUI to resize partitions and basically do everything from a GUI.
In Windows its a bit more complicated than that, as explained above.
So nice try, but even partition-wise, Ubuntu/Kubuntu have easier installers.
just sawing a limb off? :-)
It should reduce sentence times but still have the same chilling effect.
Its not 1998. Try Ubuntu/Kubuntu out.
You don't need to know anything to get those running.
Their installation is far easier than the Windows installation, and most of the common things people do "just work". Those rare occasions that don't "just work" have very simple step-by-step howto's all over the place.
Try Ubuntu/Kubuntu.
They don't strip away your choices, but they sure dumb them down so unless you really want to - you are not aware of having to make any decision.
Linux is ready for the desktop - and it is already in many desktops.
Many people don't use it not because its not ready, but because they don't know how to burn a CD, how to boot from it, what "installing an OS" means, and because they are afraid. Not because Linux "is not ready" and any of that nonsense.
Reasons for why the web is terrible (and thus no web apps can be contenders for "the best apps ever"):
There are many more reasons for why the web sucks. But the main idea is that instead of extending local GUIs to reasonably and securely run over a network, they took static data formatters that can read data from a network and extended them to support rich GUIs and scripting. This is simply wrong, and I really hope that more people see how wrong this is as soon as possible.
But they only have to maintain source-level compatibility. Microsoft has to maintain binary-level compatibility.
Also, when specific things are extremely and seriously broken, compatibility can be dropped altogether, and some buggy programs broken. Microsoft cannot afford to break buggy programs, even if those are few and far between - nobody can fix them.
Using a multi-threaded approach here, when SMP scalability is not an issue, suggests that either their API design is crap, and requires threading, or that their engineers are incompetent and use threads unnecessarily. Threads are never trivial - but what they were trying to do was quite trivial. Its their fault they involved threads in there.
Compare the complexity of APIs. fork/exec vs CreateProcess. open vs CreateFile. To use either of the Windows ones you have to call multiple APIs with multiple complicated structures documented upon pages and pages of explanations you must do more than skim through.
Windows may have similar complexity in some subsets of its APIs, but the Windows APIs I had the misfortune to use were insanely complicated unnecessarily.
Its not magic, maybe, its a registry filename.
Microsoft, in its stupidity and/or attempt to complicate their system so that potential compatibility is more difficult, duplicated the functionality of the "file system" with the registry. That makes registry keys such as CLSID's filenames too. The grandparent was right in calling them magic file names.
Its only useful in a closed-source world where you cannot modify programs to suit the new API's.
It accumulates complexity over time.
The result is that even Microsoft can't get reasonably trivial things right.
Not to mention almost all Windows software code being highly complicated compared to equivalent code on other systems.
There is already a comparison function written for each type of object (especially ints and strings, the only objects sort can really compare).
Piping objects is a super-set of the power of piping textual strings, as a sibling poster mentioned: You can always convert objects to strings, but not vice versa.
A powershell equivalent (with my own invented syntax):
du -x / | sort
Ofcourse since "du" outputs numbers, sort will already compare them properly, whereas with text-strings, you have "weak typing" and need to re-specify how to correctly interpret the data (sort -n)
Objects can represent themselves in any meaningful way you want. As text, too. So you don't need a debugger either.
Debugging and generally programming the shell would become easier as you will be communicating your intent, rather than using ad-hoc string encoding/recoding techniques to get the data through the tools.
An object powershell is more powerful than a shell, kind of like Python is more powerful than bash, except that unlike Python, its syntax is designed to be easy for one-liners.
I think that's what people are saying here: "We don't like it, so we don't use it."
I guess they are saying this as they are hoping that the OpenBSD folks realize that their user base is small enough as it is to use such user-alienating tactics.
As some people here have mentioned, web pages can get into "Google hell" by being referred to from unrelated sites. Web pages can get a spam penalty for sitting next to a viagra site.
So, can't I just buy links for my competitor's website, on a site that links to various spam/viagra sites?
If its so easy to crash into Google Hell and so hard to get out, isn't it too abuseable?
You are forgetting the distributions here.
They can insert whatever patches they want into the kernels they use.
Their role here, is to integrate GPL software from various vendors. And there are many distributions, I doubt all of them do all the worrying about alienating a kernel developer. Once one distribution gets it to "just work", pressure is put on the rest to do the same.
I think the "mainline kernel" (as distributed by Linus Torvalds) is less important now, as the main channel of distribution of kernels (and most other packages) are the distributions and not the authors. This is great, as one coordinating entity can make all the required changes and integrations to GPL'd software to make it work together.
It may be that most users will download it directly because it is free as in beer. But they are also directly downloading it because of its functionality.
And its functionality was made possible because it is Free as in speech and for no other reason.
And if their functionality suddenly breaks because a closed-source distributor decided to give up their support for Linux - or nVidia stops maintaining their drivers, they will stop using Linux just the same.
So Free Speech is an important aspect in building the functionality and maintaining a system that will work independently of business interests. Pushing for Free as in Speech software in Linux should not be underrated, even if you come from a functional, rather than a philosophical, standpoint.
unsigned char number_of_copies;
'nuff said.
When you enable Changes' tracking and have lots of "advanced features" (tables, images, etc) in a large document -- you definitely get some keystroke lag, even on pretty modern machines.
I used to turn off changes' tracking so Word would not be so slow on my larger documents.
Hey, I am a big Debian/Ubuntu fan myself.
I believe it has just recently made it clear that it surpasses the quality of Windows not just on the server, but on the desktop as well (2 Years ago it was not clear, and for many reasons leaning towards Windows as better).
I believe that in the future (perhaps 5 years or more), your point will be true. However, to say that there is more software written that works with Debian than with Windows (based on a "package count") is indeed bogus.
There is probably a lot more written for Windows, maybe even more functionality available - though to legally access it, a user would have to pay thousands of different entities insane amounts of money. There are a lot of invisible software packages for niche users that you never hear about, unless you work in a geological surveying company, or whatever.
Ubuntu is gaining critical mass, and its development seems to be accelerating every year. It truly seems that Microsoft is not keeping up the pace, and in a few years, I believe and hope that even ordinary users will be convinced that GNU Linux desktops are overwhelmingly better. Silly fronts like "beryl", I believe, are actually the weapon that works best against Microsoft users.
You have to type it in a specific text box - that of your package manager.
And then, the various alternatives are 1 click away.
That is never true in Windows, it is much more difficult and involves far more to find, download and install from the web. And far worse, it involves far worse trust in untraceable entities! My packages are signed by the maintainers who registered themselves and are trackable.
I didn't say you couldn't legally download, I said you couldn't download the updates for your entire software repository (including not just Microsoft software, but also your games, your Instant Messangers, Photo editors, etc) from one central location, which remains true.
Talk about nitpicking! Yes, some fuel is burnt (unless wind or solar power is powering those routers, ofcourse), but to compare that to the fuel burnt to power the car to and from the store to carry the bits is absurd.
You can't just type in office in your package manager window, and click open office for it to be downloaded and installed for you. As well as showing you one-click-away offices right next to it, too.
In Windows, you have to find the office suite in various web sites, and click quite a few more than one click to actually download it, after which you have to click more to run the untrusted executable (In Linux, my downloads are signed by a trusted repository and trackable entities).
I did not say you couldn't download it - I said you couldn't download it and install it as easily as in Linux.
That's a little exaggerated. One internal function calling another can "trust" the neighboring function, as long as it is used internally and closely. Allowing this encourages the use of tiny trivial functions that can be reviewed.
I've actually seen people write every function with a large documentary skeleton, either asserting on every condition of every argument, or checking them with error codes.
That's great for inter-module API functions. It is. It is even better than the other extreme (The Microsoft-ish trust-all).
But using such checks for internal functions results in:
So I would say: Never trust input that comes from external sources. And now the problem becomes defining external. But input from a file (a
Welcome to the world of poorly designed software.
Too expensive to fix a de-serialization operation of document data?
Ouch, someone must have hired incompetent software designers!
Hahahaha!
That is so early 90's!
Hello?? We have the internet!
Software can be downloaded!
In Windows, I can't just type in "office", click the resulting "kde office" and "open office" programs, and have them automatically downloaded for me, without fuel being burnt to get the bits from there to my computer. Amazing!
Also, I can just type in almost anything I may want my computer to do - and behold, one of more than 10,000 programs shows up which can be installed with a single click!
Oh wait, there's more. When I play a movie in full-screen, a bunch of "Would you like to update me?" dialogs of various programs don't jump up at me!
In fact, *all* (and that means all software you have) updating is done from a central location - by clicking the update icon.
Oh, Windows doesn't have that? Pitty, maybe I should stick to Linux!
By the age kids can play these games at all, they are already exposed to advertisements, to the internet and to modern television.
Are there any innocent kids left in the western world?
I am not saying this is necessarily a bad thing, but I think that kids born in the 90's are not nearly as innocent as those before the 80's, and the whole "childhood" concept has changed considerably.
Actually, GPL code is allowed to use BSD code.
BSD code is unallowed to use GPL code.