This "problem" also exists in GNOME and KDE. Trouble is, it's not a "problem", it's a feature.
Back in the days of application-centric environments, such as DOS and pre-desktop Unix, you first opened the application then used it to open the document. But today's computing world is document-centric. You open a document and the appropriate application comes up with it. This is a Good Thing(tm).
If it's Evil for Windows to do this type of stuff, then it's equally Evil for KDE to default to KView instead of GIMP when you open up a jpg or png. But of course it's NOT evil for this sort of behavior. We know that we can choose "Open With..." or change the default behavior. The situation is exactly the same for Windows users. If there is a problem, it is that Windows users tend to never bother trying to find out how to change things.
That's the window style plugins. Choose another window style if 5 buttons bother you. Or write your own. One of the best parts about the KWin architecture is its plugin decorations.
This isn't Windows. You don't have to stick with the default configuration. Choose the KStep decoration with only two buttons if you wish.
Not all distros are like that. Redhat likes to stick its fingers in everything, but Redhat ain't Linux.
My favorite distro is Slackware. Just the basics. Enlightenment is enlightenment is enlightenment. KDE is KDE is KDE. Patrick does what he does best, and that's to integrate everything together into a system. There's no need for him to issue linux-2.4.10-pv9.4.2-pre6 kernels, or tweak the default themes because they aren't purple and gold, or green and white. GNOME and KDE don't get a million new menu items for all the stuff you never installed. etc.
And according to the KDE 3.0 TODO list, KWin is undergoing a major overhaul.
Having poked and prodded the insides of KWin, it is a very nice window manager. Small, fast, elegant. The philosophy seems to be just manage windows, nothing else. (sort of like sawmill). I don't know much they could do to improve it.
Please, oh please, don't call the meta key "Win"! Just because my keyboard has three keys with funny symbols on them, don't assume that I am a MS Windows users. I mean really! If I were a Windows user, I wouldn't be using KDE now, would I!
There should be an explanation somewhere that the key on most PC keyboards with the MS logo is the "alt" key. That goes without saying. But don't rename it!
For example, commenting about their kitchen sink tactics, even while admitting that KDE has become a kitchen sink in in the very next sentence.
I didn't say KDE had the kitchen sink included, but I will cede the point. What I am arguing is that it *shouldn't* have the kitchen sink.
Not every KDE application needs to be a part of the core KDE. Keeping KOffice as its own project is a Good Thing(tm). Other ideas of that magnitude should be separate projects as well.
In OO design, you have the eternal war between cohesion and coupling. High cohesion is good (classes to only one thing). Low coupling is good (classes are independent). But high cohesion leads to high coupling, and vice versa.
MVC is a good design and has a nice balance between cohesion and coupling. Unfortunately, like all good designs, templates and patterns, once you overlay it with a real application it's not so perfect anymore.
Data aware widgets have high coupling. But in turn they get high cohesion. If that level of cohesion is desired (a component, for example), then there's not much you can do about it, MVC or otherwise.
KDE is a *desktop*, not a productivity suite. Microsoft may be attempting to add everything but the kitchen sink into their desktop, but that's not the way we do things in Unix land.
In my never humble opinion, keep KDE a desktop and infrastructure, and spin off the extra stuff into their own projects (like they did with KOffice).
Considering you said "GPL on the otherhand is the best of both free and proprietary," I would wager good money that it's you who are the idiot. Why in hell would I wish to use a license you claim is the best of proprietary?
Does the uncertainty of having a retail publisher for FreeBSD have anything to do with the fact that 4.4 was released as a 4-iso set for download?
No. The reasons why the ISOs are available is because the "free" in FreeBSD means "free". As in BOTH gratuis and libre. Download it for no cost then use it with no restriction.
There once has a fabulous apple tree. No matter how many apples one would take from it, there were just as many as before! When this was heard by the villagers they all rushed to the apple tree and took apples. But no matter how many they took, there were just as many apples as before. But some of them came and took apples and locked them within a chest, so that none could steal them. And they laughed at the other villagers, saying, "Look, they do not protect their apples. Surely a thief will come and steal them."
Let Walnut Creek become an independent CD-ROM reseller again
The days of Walnut Creek of over. It's sad but it's true. Back when everyone had a 14.4K connection to the internet, downloading FreeBSD, Slackware, CICA, Simtel, Hobbes, etc., was not feasible. They made their money because it was cheaper to buy the CDs than to download the software.
The situation is much different now. The abundance of broadband connections and CD burners has changed the CDROM market. From the reports before the BSDi sale, Walnut Creek had been generating less and less revenue over the previous few years.
There is still a market of "official" FreeBSD and Slackware sets, but I don't see that market driving a viable business. There needs to be other things driving revenue as well.
I just ran across a GNOME problem not just ten minutes ago. I want to build Dia because argouml is insufficient and Rose sucks.
Dia is under GNOME/stable. gdk-pixbuf is under GNOME/unstable. Anyone see the problem here? Who in their right mind can call Dia "stable" when it relies on an "unstable" library?
Huh? This is like banning hammers just because people have been known to hit their thumbs with them.
If you don't know how to use strings, you will get burned everytime. But if you do know strings, and are aware of the tarpits, then every one on your list is perfectly fine.
The number one security problem in C is not strings, but the lack of unit and system testing. Do you unit test every one of your functions? Does someone other than you or your end user perform system testing? Do you even have a test plan?
The trouble is that most Linux distros come with NFS, BIND, Sendmail and rlogin/rsh installed by default. They're getting a bit more savvy about this, but it's still a major problem. If you're a competent administrator, you can deal with it. Most people aren't. I certainly am not, which is why I prefer systems that don't turn on every damned vulnerability known to man.
Too many distros want to make you do all of your sysadmining from DistroConf2. You don't tune your automobile engine from your dashboard, and you don't secure your system from a GUI.
The purpose of education is to learn. When you are attempting to learn programming, it does absolutely no good if you don't do it yourself. Or to put it another way, you will learn a LOT more if you try to figure out how to create your first linked list by yourself, rather than having your buddy tell you how to do it. Problems the professors give you are meant to make you think. It does you no good if someone else does the thinking for you.
You will learn more about "off by one" errors if you spend hours trying to figure out what's wrong with your code, than if your buddy says "hey, don't forget to count to foo-1 instead of foo".
This is for lower division courses. For upper division, when you have already demonstrated you know the languages and basic constructs, then working in groups should be standard.
Okay, let me attach some bait to the hook, drop down the line, and start trolling...
...it's nice to see vim sticking by it's one of it's principles - making a lightweight editor.
vim is lightweight? What have you been smoking, and why won't you share?
vim is only lightweight in comparison to emacs. It ain't lightweight compared to the vi family. It's like your 300 pound rube cousin you hate to invite for Thanksgiving because you'll have to cook two turkeys, and rent a spare sofa for the bowl games because the la-z-boy ain't big enough. The only thing that makes him tolerable is that he ain't your 500 pound neighbor emacs:-)
Slashdot Mirror
This "problem" also exists in GNOME and KDE. Trouble is, it's not a "problem", it's a feature.
Back in the days of application-centric environments, such as DOS and pre-desktop Unix, you first opened the application then used it to open the document. But today's computing world is document-centric. You open a document and the appropriate application comes up with it. This is a Good Thing(tm).
If it's Evil for Windows to do this type of stuff, then it's equally Evil for KDE to default to KView instead of GIMP when you open up a jpg or png. But of course it's NOT evil for this sort of behavior. We know that we can choose "Open With..." or change the default behavior. The situation is exactly the same for Windows users. If there is a problem, it is that Windows users tend to never bother trying to find out how to change things.
That's the window style plugins. Choose another window style if 5 buttons bother you. Or write your own. One of the best parts about the KWin architecture is its plugin decorations.
This isn't Windows. You don't have to stick with the default configuration. Choose the KStep decoration with only two buttons if you wish.
I'll dispute the label of "fucktard", but I will admit to needing a WYMIWYT(*) interface to Slashdot.
(*) "What You Mean is What You Type"
Not all distros are like that. Redhat likes to stick its fingers in everything, but Redhat ain't Linux.
My favorite distro is Slackware. Just the basics. Enlightenment is enlightenment is enlightenment. KDE is KDE is KDE. Patrick does what he does best, and that's to integrate everything together into a system. There's no need for him to issue linux-2.4.10-pv9.4.2-pre6 kernels, or tweak the default themes because they aren't purple and gold, or green and white. GNOME and KDE don't get a million new menu items for all the stuff you never installed. etc.
And according to the KDE 3.0 TODO list, KWin is undergoing a major overhaul.
Having poked and prodded the insides of KWin, it is a very nice window manager. Small, fast, elegant. The philosophy seems to be just manage windows, nothing else. (sort of like sawmill). I don't know much they could do to improve it.
Please, oh please, don't call the meta key "Win"! Just because my keyboard has three keys with funny symbols on them, don't assume that I am a MS Windows users. I mean really! If I were a Windows user, I wouldn't be using KDE now, would I!
There should be an explanation somewhere that the key on most PC keyboards with the MS logo is the "alt" key. That goes without saying. But don't rename it!
For example, commenting about their kitchen sink tactics, even while admitting that KDE has become a kitchen sink in in the very next sentence.
I didn't say KDE had the kitchen sink included, but I will cede the point. What I am arguing is that it *shouldn't* have the kitchen sink.
Not every KDE application needs to be a part of the core KDE. Keeping KOffice as its own project is a Good Thing(tm). Other ideas of that magnitude should be separate projects as well.
In OO design, you have the eternal war between cohesion and coupling. High cohesion is good (classes to only one thing). Low coupling is good (classes are independent). But high cohesion leads to high coupling, and vice versa.
MVC is a good design and has a nice balance between cohesion and coupling. Unfortunately, like all good designs, templates and patterns, once you overlay it with a real application it's not so perfect anymore.
Data aware widgets have high coupling. But in turn they get high cohesion. If that level of cohesion is desired (a component, for example), then there's not much you can do about it, MVC or otherwise.
KDE is a *desktop*, not a productivity suite. Microsoft may be attempting to add everything but the kitchen sink into their desktop, but that's not the way we do things in Unix land.
In my never humble opinion, keep KDE a desktop and infrastructure, and spin off the extra stuff into their own projects (like they did with KOffice).
You are an idiot.
Considering you said "GPL on the otherhand is the best of both free and proprietary," I would wager good money that it's you who are the idiot. Why in hell would I wish to use a license you claim is the best of proprietary?
Commercial funding Open Source BSDs may be at death's door, but the system's themselves are alive, kicking, and stocking up on cans of Whoopass.
Hmm, 4.3 came with stickers, but 4.4 hasn't been mailed yet (next week I think). I sure hope it has stickers.
Does the uncertainty of having a retail publisher for FreeBSD have anything to do with the fact that 4.4 was released as a 4-iso set for download?
No. The reasons why the ISOs are available is because the "free" in FreeBSD means "free". As in BOTH gratuis and libre. Download it for no cost then use it with no restriction.
There once has a fabulous apple tree. No matter how many apples one would take from it, there were just as many as before! When this was heard by the villagers they all rushed to the apple tree and took apples. But no matter how many they took, there were just as many apples as before. But some of them came and took apples and locked them within a chest, so that none could steal them. And they laughed at the other villagers, saying, "Look, they do not protect their apples. Surely a thief will come and steal them."
Hell Yes! BSD is too free! But the GPL doesn't go far enough. If you really want to keep people from stealing the code, make it proprietary.
The more restrictions the better.
Let Walnut Creek become an independent CD-ROM reseller again
The days of Walnut Creek of over. It's sad but it's true. Back when everyone had a 14.4K connection to the internet, downloading FreeBSD, Slackware, CICA, Simtel, Hobbes, etc., was not feasible. They made their money because it was cheaper to buy the CDs than to download the software.
The situation is much different now. The abundance of broadband connections and CD burners has changed the CDROM market. From the reports before the BSDi sale, Walnut Creek had been generating less and less revenue over the previous few years.
There is still a market of "official" FreeBSD and Slackware sets, but I don't see that market driving a viable business. There needs to be other things driving revenue as well.
I'm looking there because I want to build Dia! Hello McFly!
I just ran across a GNOME problem not just ten minutes ago. I want to build Dia because argouml is insufficient and Rose sucks.
Dia is under GNOME/stable. gdk-pixbuf is under GNOME/unstable. Anyone see the problem here? Who in their right mind can call Dia "stable" when it relies on an "unstable" library?
"Hmm. No. Java strings, Perl strings, C++ strings are absolutely *immune* to buffer overflows."
Is your solution then to abandon C?
"Testing is a part of the solution, it's not the end-all be all."
Of course. But it's a basic tool. Not testing your code is much worse than using string functions. I mean BOTH unit tests and system tests.
Huh? This is like banning hammers just because people have been known to hit their thumbs with them.
If you don't know how to use strings, you will get burned everytime. But if you do know strings, and are aware of the tarpits, then every one on your list is perfectly fine.
The number one security problem in C is not strings, but the lack of unit and system testing. Do you unit test every one of your functions? Does someone other than you or your end user perform system testing? Do you even have a test plan?
The trouble is that most Linux distros come with NFS, BIND, Sendmail and rlogin/rsh installed by default. They're getting a bit more savvy about this, but it's still a major problem. If you're a competent administrator, you can deal with it. Most people aren't. I certainly am not, which is why I prefer systems that don't turn on every damned vulnerability known to man.
Too many distros want to make you do all of your sysadmining from DistroConf2. You don't tune your automobile engine from your dashboard, and you don't secure your system from a GUI.
The purpose of education is to learn. When you are attempting to learn programming, it does absolutely no good if you don't do it yourself. Or to put it another way, you will learn a LOT more if you try to figure out how to create your first linked list by yourself, rather than having your buddy tell you how to do it. Problems the professors give you are meant to make you think. It does you no good if someone else does the thinking for you.
You will learn more about "off by one" errors if you spend hours trying to figure out what's wrong with your code, than if your buddy says "hey, don't forget to count to foo-1 instead of foo".
This is for lower division courses. For upper division, when you have already demonstrated you know the languages and basic constructs, then working in groups should be standard.
The designers at BMW do not really want you painting their cars in hippie rainbow colors, adding neon underneath and gluing crap to the hood.
But the designers at BMW aren't going to sue me if I paint the Virgin Mary on the hood!
Or an emacs user, in which case they are wrong, lying and criminally insane
Hey wait! We may be lying and criminally insane, no doubt about it, but we ain't wrong!
Okay, let me attach some bait to the hook, drop down the line, and start trolling...
...it's nice to see vim sticking by it's one of it's principles - making a lightweight editor.
:-)
vim is lightweight? What have you been smoking, and why won't you share?
vim is only lightweight in comparison to emacs. It ain't lightweight compared to the vi family. It's like your 300 pound rube cousin you hate to invite for Thanksgiving because you'll have to cook two turkeys, and rent a spare sofa for the bowl games because the la-z-boy ain't big enough. The only thing that makes him tolerable is that he ain't your 500 pound neighbor emacs
If you want lightweight, try elvis.