Why such emphasis on OO paradigm? While building the system, did you have trouble bending some things around OO model (i.e. could some things be only done in straight C)? Do you think many developers will be turned off because objectOriented style of variable and function naming was used in the C parts of the source (as I noticed)? Finally, why do you want this to be a primarily desktop OS? What do you think of the current desktop environment offerings in *nix world?
This will probably me moderated as flamebait, but anyhow.
VA didn't make much money with run-off-the-mill PC hardware. Sure they could capitalize on the dot-bomb hype of 2000 (when some places were too lazy to install Linux themselves, check hardware compatibility, etc, and were willing to pay VA for a box with preinstalled Linux). One would think that now for VA the services is where it's at, but if they can't even generate much revenue with the services what's left? Oh wait, we have developed a web application that was never meant to go commercial, but since now it might very well be our last chance to stay afloat, what the hell. And if that doesn't go well (I can't see how this can be as popular as VA would need it to generate revenue) it's definitely bust for VA.
There's much more cruft in C++ than there's in C. C++ lets the programmer go lazy on many things at the expense of bloat and execution speed. Even "Hello world" examples are much larger in size than C equivalents. The sheer size of the download should give you an idea. The loading times don't worry me as much as the memory usage. Same goes for Mozilla. Mozilla is a huge beast and will use lots of CPU often (not even mentioning all the memory leaks).
Bottom line: I can't use KDE 2.2 on my 128 MB machine, it's just not enough. KDE 2.2 plus Mozilla, and I am sitting waiting for the swapping to churn through.
Also compare GNOME core distribution ( mostly C) and KDE core distribution sizes. Granted GNOME doesn't offer as many features, but the difference is quite apparent.
Here's what I'd like to see
on
KDE 2.2 Released
·
· Score: 3, Interesting
Less bloat. More optimizations. You shouldn't neet lots of resources to move windows around and copy and paste. 1.x release was actually bearable on a 64 or 128 MB machine, can't say the same about the new release. I know this is asking for impossible, but maybe people who moderated my previous post a troll can prove me wrong, and have a large C++ project have a memory foot print/resource usage that these kinds of binaries could have (C instead).
Re:Work with the GNOME people (and vice versa)
on
KDE 2.2 Released
·
· Score: 1
Work together? I think clashing between GNOME and KDE is similar to clashing between the three BSD groups. They do things differently, and can't get along since the project goals are different, the technology is different, the zealotry doesn't help either.
These applications are CPU bound. The OS of choice won't be doing much at all. As long as your machine is fast enough, the OS choice becomes a matter of preference. Solaris, *BSD, Linux, IRIX, HP/UX, even Mac OS X will do fine here. It's a cluster where application for rendering is parallelized (MPI/PVM type libraries). Or distributed, where the same application runs on a different data set on each machine. In any case, the OS is not a bottle neck, the hardware is. You only run a handful of processes, and you're not doing much I/O (unless it's fluid dynamics you're modeling, where I/O is important).
Don't take this as a flame, but I don't think it's easy to slim down a project like this. It's OO, it's C++, what can be expected? C++ is a higher level language, resulting in slow compilation times and bloat. The gain is shorter developement cycle at the expense of bloat. Same goes for Mozilla.
IIS works just as well as Apache. Anyone who says that one is great while the other is worthless has definitely got some agenda of his own and is not even attempting an objective comparison.
First, IIS only runs on Windows with all its implications.
Technology, quality, portability, support, vendor lock-in and many other useful factors should be decisive when choosing a product for a project, not marketing hogwash be it from MS or anyone else.I wouldn't want you as my boss if I knew you didn't care what products run your company "as long as they work". Or as long as MS or someone else is a market leader. Tying yourself to a platform because you've been brainwashed by clever marketing is not going to take your company far. It will lead to a vendor lock-in and everything else that comes with it. But you probably already know it, since your post sounds like the troll that it is
TCP/IP is there, HTTP is there, heck even XML is there if you want to go that high of a level and bloat. Web-based applications can exchange information in many ways. What's different about web services?
Right on! You have to be a total knock-knock not to be able to realize just how much Sun is trying to push Java down everyone's throat. As for Microsoft they're simply hyping a non-existant developement platform just to brainwash PHBs. PHBs then will be hiring MCSEs and VB losers who switched to C#. "It's just a job", most of them will say. "We're not _really_ technically inclined". So they went to Computer Learning Center, passed their MCSEs, and now they're shiny blue C# developers. More power to them. More crappy corporate websites, more bloat, more MS monopoly, more code red type crap. Choose the tool based on technical merit and suitability for the project, not the lies and MS bullshit. Though if you've been brainwashed enough by MS it's probably too late.
Good and useful techonology doesn't need to be hyped or even cost anything. Python, Perl, GCC, Linux distributions, FreeBSD, OpenBSD, NetBSD, Apache, PHP among many others are good examples of good and useful techonologies that didn't need to be hyped.
It doesn't matter which distribution you choose, but...
One thing that you need to realize is that in *NIX GUI (X) is not a necessary part of the OS. In fact you won't run it on a server. Most of the things are accomplished by starting processes in the shell and telling them what to do. You shouldn't start learning any *NIX with a GUI, period. GUI is there for GUI apps and convenience, not an essential tool needed to run the system.
That said here's what to IMHO to do:
1) Read hardware compatibility information lhd.datapower.com is one of the good places to go to.
2) Learn the basic *NIX commands from a book.
3) Understand how the system is set-up (FS layout, where things usually go), everyone must know and understand this. Also, simple commands and pipes and redirection. If you want you can do basic pipes and redirection in DOS first.
4) Everything is a file. (Though this could be understood after you install and play.)
5) Read how to install it. Install it. cd/usr/doc, and learn what you have to know.
I haven't done this in about 3 years. I remember l0pht or some other famous internet security group still had one about a year or two ago. Maybe they still do.
When I was 15-16 years old, my primary computer interests were developement and general computer knowledge. I was so carried away with my PC that I was developing in C and assembly. That year I bought a 28.8kbps modem and everything went down the drain. I stopped learning programming languages, and my interest focus has shifted to Usenet, file downloads, IRC and a famous MUD known as TCZ.
Whatever you were smoking, was definitely frying your brain. LDAP is a directory access protocol, NOT a file sharing protocol.
A better way to share storage is something akin to GFS from Sistina Software.
Remember how IBM tried to keep the API between OS/2 and Windows compatible, and MS simply added more incompatibilities to the API? Same game plan here. Microsoft was probably shocked to find SAMBA to be quite a quality product. Why would I pay for NT server license to set-up a file server, if I can just use anything else that runs Samba?
This is probably going to be moderated down, but still I think many people can associate with the folloing babble.
I've met a few developers who are completely ignorant about OS and process-level stuff.
I see a trend where people start in a RAD environment languages like VB and VB script, and now Java and Kylix without any fundamental computer concepts. They've never developed in lower level languages like C. They do not have even slightest, general understanding of microprocessors, RAM, stack, heap, pointers, memory allocation/deallocation, memory leaks and so on. IMHO anyone starting out in a RAD environment without understanding of computer primitives is contributing to a trend of writing poor quality software. How many colleges and universities are out there who do not require their students to take C or assembly classes as prerequisites for higher-level languages? The common result is a clueless CS or IT degree graduate (in addition to most establishments' ignorance about their students' real knowledge; heck, my university didn't even provide computers in the classroom ).
The most important concept they are missing is that a computer is a state machine.
Many languages today encourage black-box approach to programming which hides state. For example in some languages objects contain methods that are executed in a sequence that a programmer is not encouraged to track. Which method is doing what at any particular point in time of the execution is not known. Furthermore, some languages like Java for instance, are shipped with a boatload of libraries that hide the plumbing. This leads to assumptions about what those libraries really do, and again poor code.
Often it is simply impossible to imagine what is going on in an OO program at run-time at any particular point in time. Not understanding how the resultant code works down to machine basics leads to hard to find bugs and poor quality and bloated software. I am not even talking about deep technical knowledge down to bits, but one should be aware of state of your application on an OS or even process level even if your language of choice doesn't require it.
It is not to say that RAD should be avoided at all costs, don't get me wrong. RAD environments and bundled languages are there for short time-to-market developement of software. This is justified because programmers are always more expensive than hardware. Nevertheless, a RAD programmer will write better code and design better software with the understanding of the lower-level plumbing. Experience with low-level languages should be a must for success with RAD-type environments and languages.
Slashdot Mirror
Why such emphasis on OO paradigm? While building the system, did you have trouble bending some things around OO model (i.e. could some things be only done in straight C)? Do you think many developers will be turned off because objectOriented style of variable and function naming was used in the C parts of the source (as I noticed)? Finally, why do you want this to be a primarily desktop OS? What do you think of the current desktop environment offerings in *nix world?
This will probably me moderated as flamebait, but anyhow.
VA didn't make much money with run-off-the-mill PC hardware. Sure they could capitalize on the dot-bomb hype of 2000 (when some places were too lazy to install Linux themselves, check hardware compatibility, etc, and were willing to pay VA for a box with preinstalled Linux). One would think that now for VA the services is where it's at, but if they can't even generate much revenue with the services what's left? Oh wait, we have developed a web application that was never meant to go commercial, but since now it might very well be our last chance to stay afloat, what the hell. And if that doesn't go well (I can't see how this can be as popular as VA would need it to generate revenue) it's definitely bust for VA.
There's much more cruft in C++ than there's in C. C++ lets the programmer go lazy on many things at the expense of bloat and execution speed. Even "Hello world" examples are much larger in size than C equivalents. The sheer size of the download should give you an idea. The loading times don't worry me as much as the memory usage. Same goes for Mozilla. Mozilla is a huge beast and will use lots of CPU often (not even mentioning all the memory leaks).
Bottom line: I can't use KDE 2.2 on my 128 MB machine, it's just not enough. KDE 2.2 plus Mozilla, and I am sitting waiting for the swapping to churn through.
Also compare GNOME core distribution ( mostly C) and KDE core distribution sizes. Granted GNOME doesn't offer as many features, but the difference is quite apparent.
Less bloat. More optimizations. You shouldn't neet lots of resources to move windows around and copy and paste. 1.x release was actually bearable on a 64 or 128 MB machine, can't say the same about the new release. I know this is asking for impossible, but maybe people who moderated my previous post a troll can prove me wrong, and have a large C++ project have a memory foot print/resource usage that these kinds of binaries could have (C instead).
Work together? I think clashing between GNOME and KDE is similar to clashing between the three BSD groups. They do things differently, and can't get along since the project goals are different, the technology is different, the zealotry doesn't help either.
Troll?? C++ binaries ARE larger than equivalent C binaries.
These applications are CPU bound. The OS of choice won't be doing much at all. As long as your machine is fast enough, the OS choice becomes a matter of preference. Solaris, *BSD, Linux, IRIX, HP/UX, even Mac OS X will do fine here. It's a cluster where application for rendering is parallelized (MPI/PVM type libraries). Or distributed, where the same application runs on a different data set on each machine. In any case, the OS is not a bottle neck, the hardware is. You only run a handful of processes, and you're not doing much I/O (unless it's fluid dynamics you're modeling, where I/O is important).
Don't take this as a flame, but I don't think it's easy to slim down a project like this. It's OO, it's C++, what can be expected? C++ is a higher level language, resulting in slow compilation times and bloat. The gain is shorter developement cycle at the expense of bloat. Same goes for Mozilla.
IIS works just as well as Apache. Anyone who says that one is great while the other is worthless has definitely got some agenda of his own and is not even attempting an objective comparison.
First, IIS only runs on Windows with all its implications.
Technology, quality, portability, support, vendor lock-in and many other useful factors should be decisive when choosing a product for a project, not marketing hogwash be it from MS or anyone else.I wouldn't want you as my boss if I knew you didn't care what products run your company "as long as they work". Or as long as MS or someone else is a market leader. Tying yourself to a platform because you've been brainwashed by clever marketing is not going to take your company far. It will lead to a vendor lock-in and everything else that comes with it. But you probably already know it, since your post sounds like the troll that it is
TCP/IP is there, HTTP is there, heck even XML is there if you want to go that high of a level and bloat. Web-based applications can exchange information in many ways. What's different about web services?
Access database for a website? That's their fault.
Right on! You have to be a total knock-knock not to be able to realize just how much Sun is trying to push Java down everyone's throat. As for Microsoft they're simply hyping a non-existant developement platform just to brainwash PHBs. PHBs then will be hiring MCSEs and VB losers who switched to C#. "It's just a job", most of them will say. "We're not _really_ technically inclined". So they went to Computer Learning Center, passed their MCSEs, and now they're shiny blue C# developers. More power to them. More crappy corporate websites, more bloat, more MS monopoly, more code red type crap. Choose the tool based on technical merit and suitability for the project, not the lies and MS bullshit. Though if you've been brainwashed enough by MS it's probably too late. Good and useful techonology doesn't need to be hyped or even cost anything. Python, Perl, GCC, Linux distributions, FreeBSD, OpenBSD, NetBSD, Apache, PHP among many others are good examples of good and useful techonologies that didn't need to be hyped.
What matters is the tool is right for the job. Apache is often the right tool for the job, and it certainly shows.
cd /usr/share/doc
It doesn't matter which distribution you choose, but...
/usr/doc, and learn what you have to know.
One thing that you need to realize is that in *NIX GUI (X) is not a necessary part of the OS. In fact you won't run it on a server. Most of the things are accomplished by starting processes in the shell and telling them what to do. You shouldn't start learning any *NIX with a GUI, period. GUI is there for GUI apps and convenience, not an essential tool needed to run the system.
That said here's what to IMHO to do:
1) Read hardware compatibility information lhd.datapower.com is one of the good places to go to.
2) Learn the basic *NIX commands from a book.
3) Understand how the system is set-up (FS layout, where things usually go), everyone must know and understand this. Also, simple commands and pipes and redirection. If you want you can do basic pipes and redirection in DOS first.
4) Everything is a file. (Though this could be understood after you install and play.)
5) Read how to install it. Install it. cd
I haven't done this in about 3 years. I remember l0pht or some other famous internet security group still had one about a year or two ago. Maybe they still do.
Yeah, I remember I was very obsessed with BBSes too. That was craploads of fun. It doesn't seem like such an attractive hobby anymore.
When I was 15-16 years old, my primary computer interests were developement and general computer knowledge. I was so carried away with my PC that I was developing in C and assembly. That year I bought a 28.8kbps modem and everything went down the drain. I stopped learning programming languages, and my interest focus has shifted to Usenet, file downloads, IRC and a famous MUD known as TCZ.
Whatever you were smoking, was definitely frying your brain. LDAP is a directory access protocol, NOT a file sharing protocol. A better way to share storage is something akin to GFS from Sistina Software.
Remember how IBM tried to keep the API between OS/2 and Windows compatible, and MS simply added more incompatibilities to the API? Same game plan here. Microsoft was probably shocked to find SAMBA to be quite a quality product. Why would I pay for NT server license to set-up a file server, if I can just use anything else that runs Samba?
So could it possibly become open-sourced?
But it doesn't have to be Linux. The BSDs would have done well. Any other Linux distribution for that matter would have worked too.
try gentoo linux. Strives to be BSD-like in administration
Uh oh, my bad. What about Kylix and VB?
This is probably going to be moderated down, but still I think many people can associate with the folloing babble.
I've met a few developers who are completely ignorant about OS and process-level stuff.
I see a trend where people start in a RAD environment languages like VB and VB script, and now Java and Kylix without any fundamental computer concepts. They've never developed in lower level languages like C. They do not have even slightest, general understanding of microprocessors, RAM, stack, heap, pointers, memory allocation/deallocation, memory leaks and so on. IMHO anyone starting out in a RAD environment without understanding of computer primitives is contributing to a trend of writing poor quality software. How many colleges and universities are out there who do not require their students to take C or assembly classes as prerequisites for higher-level languages? The common result is a clueless CS or IT degree graduate (in addition to most establishments' ignorance about their students' real knowledge; heck, my university didn't even provide computers in the classroom ).
The most important concept they are missing is that a computer is a state machine.
Many languages today encourage black-box approach to programming which hides state. For example in some languages objects contain methods that are executed in a sequence that a programmer is not encouraged to track. Which method is doing what at any particular point in time of the execution is not known. Furthermore, some languages like Java for instance, are shipped with a boatload of libraries that hide the plumbing. This leads to assumptions about what those libraries really do, and again poor code.
Often it is simply impossible to imagine what is going on in an OO program at run-time at any particular point in time. Not understanding how the resultant code works down to machine basics leads to hard to find bugs and poor quality and bloated software. I am not even talking about deep technical knowledge down to bits, but one should be aware of state of your application on an OS or even process level even if your language of choice doesn't require it.
It is not to say that RAD should be avoided at all costs, don't get me wrong. RAD environments and bundled languages are there for short time-to-market developement of software. This is justified because programmers are always more expensive than hardware. Nevertheless, a RAD programmer will write better code and design better software with the understanding of the lower-level plumbing. Experience with low-level languages should be a must for success with RAD-type environments and languages.