The Xeon has double the cache, is double the price, and isa top end server chip, being compared to a midrange desktop chip.
There is no significant difference between the Xeon and the P4 cores. As far as having double the cache, that is simply a part of the design. Are you going to say the same thing when the EM64T Prescotts (complete with either 1M or 2M L2 caches) are released? The Prescotts are obviously aimed for the desktop but *gasp* will have 2X the L2 cache as the AMD desktop Athlon 64s and may likely have 2X the L2 cache as the Opterons at some point. The current Prescotts all have 1M L2 cache... does that mean we can't compare any of them to any Athlon 64 Newcastle core?
The amount of cache, clock speed, etc. are all parts of the design. You compare one CPU vs. another, not one CPU's individual pieces to the other CPUs individual pieces to the other.
The AMD is running at 2.2 ghz, and retails $500 less. To me this says AMD is working smarter and Intel is working harder.
To me, it says that the two designs follow different philosophies. Intel's design is narrower than the AMD design (Athlon 64s have more execution units than the P4). The logic and design of the AMD chip make it harder for them to reach higher clock speeds - by choice somewhat as AMD has designed the thing to keep the number of pipeline stages low. Intel's design reaches higher clock speeds at the expense of work done per clock. To be honest, it's harder to get the thing to run at high clock speeds than it is to just add more execution units.
RTFA usually helps.... directly from the Conclusions section:
Although the Athlon 64 3500+ and the Xeon 3.6GHz EM64T processors were not necessarily designed to compete against each other, we found that comparing the two CPUs was more appropriate than anticipated, particularly in the light of Intel's newest move to bring EM64T to the Pentium 4 line. Once we obtain a sample of the Pentium 4 3.6F, we expect our benchmarks to produce very similar results to the 3.6 Xeon tested for this review.
Without a doubt, the 3.6GHz Xeon trounces over the Athlon 64 in math-intensive benchmarks. Intel came ahead in every severe benchmark that we could throw at it, particularly during John the Ripper. Even though John uses several different optimizations to generate hashes, in every case, the Athlon chip found itself at least 40% behind. Much of this is likely attributed to the additional math tweaking in the Prescott family core.
That's not to say that the Xeon CPU necessarily deserves excessive praise just yet. At time of publication, our Xeon processor retails for $850 and the Athlon 3500+ retails for about $500 less. Also, keep in mind that the AMD processor is clocked 1400MHz slower than the 3.6GHz Xeon. With only a few exceptions, the 3.6GHz Xeon outperformed our Athlon 64 3500+, whether or not the cost and thermal issues between these two processors are justifiable.
We will benchmark some SMP 3.6GHz Xeons against a pair of Opterons in the near future, so check back regularly for new benchmarks!
I don't understand your post at all. The Athlon line has historically been the better of the two (compared with Intel's P3 and P4 line) CPUs in FPU performance. In fact, the Athlon 64 and the Nocona both support x87, MMX, SSE, and SSE2 instruction sets.
There were other issues as well... These are some of the ones I saw where I was (I worked on clustering as well back then, we just got beaten to the published paper by them so they got the name). Here are some of the issues, in no particular order.
- many of the engineering and science centers were already very deep into the Unix workstation vendors and were used to the service, stability, and performance of the Unix boxes - Sun, SGI, HP, etc. Many of them didn't want PCs to come into the system because they would require lots of support (at the time back then, PCs were notorious for being maintenance issues with only one or two boxes, much less potentially 100s).
- 32-bit. Many codes ran on machines and expected large memory models (yes, even in distributed codes). The codes would have to be tweaked a bit to run in the smaller memory footprints.
- Performance in floating point. Back then, PCs weren't as fast as the Unix boxes. It wasn't until the PPro when the performance gap started closing/inverting. You could use 10 Suns or 20 PCs to get the performance. Of course, back to the logistics/support problem of any PC, much less 2X as many.
- Viable OSs. In 1995, Linux was still fairly fledgling. It worked, but there were lots of holes (feature holes and such). The only other alternative was to run a Windows variant. Neither really worked that well at the time. GCC on the x86 back then was pretty nasty too. On the same hardware in compute intensive code, we regularly saw 2X the performance on codes we compiled when running Windows with MSVC compared to the same hardware running Linux or Solaris (because of gcc).
- Reuse. Many centers used research money to buy new machines, which would then fold back into the infrastructure of the place when the research contract was over. As I mentioned before, they were already deep into the Unix workstations. Having a research project buying a bunch of PCs wouldn't eventually really improve the Unix workstations that they have in the place.
But just because in the *nix world things are done differently, and at the same time Windows users are to damn lazy to learn anything new,
You know... I can't remember a single episode of ST:TNG or ST:TOS or any other Sci-Fi show that portrays computers in the future where someone sits down at a terminal and types stuff like:./configure make make install
I think computer interfaces have been trying to evolve for ease of use and removing as much of the workings from the hands of users as they can. It seems funny that the F/OSS community prides itself on being "future bound" so despirately clings to archaic typing and obscure character sequences to do things.
There are different definitions of the term: some (probably: most) apply to the USA, the more specific ones don't. However, most people usually deal with the more general terms and maybe are not even aware of the meaning of the more specific term. The burden of dealing with any ambiguity rests with those who are aware of the different meanings...
I'm just always reminded of those tests that say choose the most correct answer:
The USA is a(n): a) Democracy b) Democratic Republic c) Communist State d) Extra-terrestrial outpost
While "Democracy" is correct, it is correct in a general sense, much like instead of calling humans "Humans" or "persons" or whatever, we should just call them "organisms" or "entities" or even "mammals" or "animals" with supposedly the same amount of correctness.
As for b) I guess most people are well aware of that. It just begs the question whether this is a good thing or not. From an outsiders point of view, the presidential election system is very weird - for instance, the existance of states which de facto already belong to one or the other party, making the elections mostly a battle for the remaining borderline candidate states. (I apologise for any incorrect terminology.)
However, you have to ask whether this is a good or bad thing...
There are a few very good arguments for representative democracies. One of the main ones is to act as a buffer between the general populace and actual governmental policy. An example of this is that if something especially tragic happens, you don't have laws such as "evict all the Muslim folks" being passed by a simple majority of voters when supposedly the calmer heads of the elected officials can temper this a bit. Of course, many of the other reasons are for logistical reasons.
In my job (developer/management/etc), I am constantly typing in things, but never transcribing. Touch typing helps you when transcribing, because you can't easily look at the keyboard while transcribing. In modern jobs, transcription just isn't important. So I believe that my needing to look at the keyboard when typing does not hurt me at all. SPEED matters, but even more than that it is what you enter that matters!
Yeah... but as a touch typist, when I program, I'm not looking at the keyboard. I'm looking at what I type and the stuff around it. So instead of imagining what I want to type, then looking down at the keyboard and typing that, then looking up and thinking some more, I can literally spend all day typing without looking at the keyboard or stopping except to rest. In this mode, my ideas go from my head to the screen, while I'm absorbing whatever else information from the screen that I do while thinking.
When my mind is completely disengaged from the mechanics of getting the characters I want on the screen (i.e. I'm not looking at the keyboard at all and am just letting my thoughts flow from my head to the screen), I can really flow.
I guess this is where I differ from other folks. I don't necessarily like to use the mouse, and in fact, I use keyboard shortcuts a lot. To switch to the mouse, I have to disengage myself from thinking and hunt for the mouse. It's pretty astounding just how much time the mouse can take to use during the day. Of course, there are lots of things the mouse is very good at, so it speeds up lots of tasks so eventually, I think it's better to have a mouse than not. But I think the combination of using a single mode of input (keyboard) and only switching to the mouse when you'd really save time (not while programming hardly ever) is more productive (at least for me).
I think the folks who really thing speed matters are those who interrupt their thought processes to look down at the keyboard to type. In those cases, they have to make up for all the lost time thinking/analyzing while they are typing and jarring their thought processes so they can go back to looking and thinking about what they are doing. In those cases, speed is essential so you can burst the typing to get it out of the way. Most touch typist programmers don't need to type fast because they don't make many mistakes and they are thinking about what they are doing while they type instead of between typing microbursts.
In soviet russia the head of state was chosen by the party - in democratic America he's chosen by the supreme court.
It helps to study in grade school, especially in Civics class. a) the USA is NOT a Democracy. b) the American public does not choose the President directly by casting votes and those votes being counted for the ultimate result.
I'll leave it as an exercise for the reader to find out why my the above statements are true. You need to know why those statements are true in order to be able to discuss Presidential elections.
and what are your links to Apple and Microsoft and some book supposed to prove?
I can point to a book somewhere that will support anything I want to claim (can point to books that say the planet Earth is flat), but it doesn't make it true.
Quick summary: All of these installs were "out of the box" installs. I used to compile my kernel almost daily back in the 90s because it was fun and neat. I don't have the time for that anymore and much prefer stability and usability over sheer performance now.
Fedora Core 2: Installation went OK. I have a Geforce2MX200 video card (maybe MX400) and there were driver problems. Certain screen savers would lock the entire machine requiring a reset button hit. Overall, it was reasonable, but I didn't care too much for it. Stuff wasn't arranged very well from my standpoint in the menus and the like.
Mandrake 10 Professional: Installation failures abound. Playing around one day after FC2 was installed, I was surprised that I could successfully install on a 20G partition that I made just to play with it some more. Eventually I figured out that a / partition larger than some value in the 20G range, it would fail install every time. A 20G / partition would install. I didn't like that, but I ran it that way for a couple days anyway. I liked Mandrake 10 Pro better than FC2 by a bit. Seemed to be a reasonably good distro other than the install issues.
SuSE 9.1 Professional: Installation went OK. I'm not as familiar with SuSE distros so some things are in odd places to me, but I can live with that. I eventually settled on this distro and run it currently. I figured it'd be fun to play around with a distro I wasn't as familiar with. I'm much more familiar with Mandrake and RedHat. Just a complete subjective feel of performance, not based on any real data, is that the SuSE is the fastest of the three, with Mandrake being close and FC2 being a ways behind. I'm sure some of it has to do with the stability and quality of the video drivers. So far, my SuSE install has been up for a month with no shut downs or anything.
If Mandrake could fix the 20G / install partition issue, I would probably have went with it all the way because of my familiarity with it. However, being as it is, SuSE seems to be the best of the three that I tried.
The problem is that Linux changes so fast that by the time any book is in print, it is outdated. Some stuff in it might be still good, but some things will no doubt be wrong (which will/can cause frustration if the person downloads the lastest version of the distro, which he/she will need to do to get the best support and bug fixes).
Could we then put a bunch of them in a big ball full of water with some small nativity type scene in it and shake it like a Snow Globe while it's running?:)
Or... how about putting a bubbler in there with something more viscous than water and watch it like a lava lamp?:)
Or... can I have them in my fish tank where I can watch the fish swim and compute at the same time?:)
The AMD64 running a 64-bit compiled binary is a 64-bit CPU. Addresses are 64-bit values (although only 40 bits are "honored" as far as the hardware goes right now). sizeof(long) == 8. etc. Doubles are still 64-bit, I don't think they do long double or anything like that (no 128-bit floats). The Intel 64-bit extention stuff is supposed to be binary ISA compatible with the AMD64 x86-64 ISA.
As far as other stuff, summaries of the AMD64 programming model can be found all over. There's probably one on ArsTechnica.
IP is only an issue if you make it an issue, which Australia seems want to do. But still there is hope for Europe and Asia who may yet still realize how much of a technological lead can be realized if they stick together and ensure their developers can create without having to fear being sued for something as silly as allowing a user to click once.
What evidence do you have that any technological lead can be had by ignoring IP? I'm not saying there can or can't be one, but I have never seen anything that would prove this assertion that so many people like to throw around as some irresputable truth. "Gut feel" and religious dogma are not sufficient proof.
Odd that 'harmonizing' is always in one direction - for some reason, no one ever wants to decrease IP regulation to harmonize with some other country.
Maybe it has something to do with making money as opposed to not making money. Remember, a company that has IP can generate jobs and make money for the government in the form of taxes. Removing IP and you just dropped the bottom out of that market, which may be profitable for developing countries.
The crux is this: we all bought in this phantom "Information Economy" in the 90's, completely bypassing the fact that the real money is made with SERVICES, not INFORMATION.
I would say that you got it backwards here. Anyone can do services. Few can produce information. Service industries make real money for the people who own the service companies. The people who work for service companies tend to be lower paid (McDonalds? BurgerKing? etc.) I know you'll say that in F/OSS that everyone owns their own company but the fact that there will be any number (perhaps many) people who can offer the service model to customers, the price for services will go down. It will be a buyers' market, not a sellers' market. In the end, the few medium-large companies will buy services from large companies (IBM, etc.) and the small companies will take all their software for free and not buy any (or very few) services.
Remember, when you pay for a boxed Linux distro, you are paying for the services that they packaged all the stuff up for you, and that you usually get like a year of service with it. If you aren't buying boxes at your work, then you are killing the service model that F/OSS so highly touts.
Completely subjective. I think KDE looks fairly asstastic, but it is better than Gnome and there's not much more choice for a reasonably featured GUI out of the box.
As far as GUIs go, I had KDE hang my machine 5 times today to the point where I had to power cycle. I haven't hung or crashed my Windows boxes in months/years.
But I guess that is their choice to make that tradeoff. I prefer proper multitasking, personally.
And that is why most people in/. have no concept of users. Most users don't multitask. They sit down and do one thing at a time. Maybe they will push something to the background but rarely is it something that crunches (move Word to the background where it is waiting on the user to type something while they pull up an email reader to send email to someone).
As far as hanging the GUI, I had Mandrake 9.2 completely lock the system hardcore solid today 5 times. The cause? I clicked the Install Software thing too many times from the GUI. I was impatient and thought I had missed so I clicked again... then again... because the thing is so responsive... Then it got into some state where the only solution was to power cycle the machine.
Actually, I already do pay for (or contribute to) F/OSS organizations. I typically buy or contribute to applications that I think are written well and do a good job that I use. I also tend to pay for "boxed" versions of Linux distributions. In addition, I also write some F/OSS software. My previous post was with some bit of sarcasm, if you didn't notice.
We are current migrating away from ms sql server. Since a lot of our app is written in Stored Procedures, a lot of the app has to be re written.
It's definately a mistake to put everything to stored procedures. Especially if you want to keep your app somewhat database independant.
This is completely false. One of the reasons TO use SPs is that you will be using multiple RDBMSs. You write your code (typically compiled code like C, C++, etc.) once and the stored procedures are written to "do the right thing" and each system returns a consistent result set or answer. That way you seperate your code from the implementation that is database specific.
If you are using embedded SQL in your code, every time you have to change a query, you have to recompile your entire app. Every time you want to port to a new RDBMS, you have to write a whole bunch of code to generate the right queries for you. At best, you designed your app from the start to see what RDBMS you are using then create an "object" that encapsulates all of your queries so they are isolated from your app. If you didn't do that, then every function you call that queries the database has to have if/else or switches to see which pathway to go down to get the right query.
Using Stored Procedures is what *keeps* your app database independent. As long as you are using real RDBMSs, you simply rewrite your.sql files to do the right thing and your app runs. Your approach of embedding all the SQL leads to massive redevelopment for every RDBMS you support.
I'm betting that the reason you are down on SPs is that you are going to something that doesn't support SPs, like MySQL (I hope, instead of not just realizing you rewrite your SPs and your app runs as it is already compiled), which you had better understand the implications since you are going from an RDBMS to just a "data dumping place". There can be some things you aren't thinking of with your MySQL migration that can really, really ruin your day down the road if you don't watch it.
Yeah... don't pay for F/OSS... let's see how many people keep doing it when they realize they can't feed themselves or their family in that business. And then seen how many companies stay around to offer support for F/OSS and then see where Linux lives.
Slashdot Mirror
The Xeon has double the cache, is double the price, and isa top end server chip, being compared to a midrange desktop chip.
There is no significant difference between the Xeon and the P4 cores. As far as having double the cache, that is simply a part of the design. Are you going to say the same thing when the EM64T Prescotts (complete with either 1M or 2M L2 caches) are released? The Prescotts are obviously aimed for the desktop but *gasp* will have 2X the L2 cache as the AMD desktop Athlon 64s and may likely have 2X the L2 cache as the Opterons at some point. The current Prescotts all have 1M L2 cache... does that mean we can't compare any of them to any Athlon 64 Newcastle core?
The amount of cache, clock speed, etc. are all parts of the design. You compare one CPU vs. another, not one CPU's individual pieces to the other CPUs individual pieces to the other.
Why not RTFA... especially the Conclusions section...
The AMD is running at 2.2 ghz, and retails $500 less. To me this says AMD is working smarter and Intel is working harder.
To me, it says that the two designs follow different philosophies. Intel's design is narrower than the AMD design (Athlon 64s have more execution units than the P4). The logic and design of the AMD chip make it harder for them to reach higher clock speeds - by choice somewhat as AMD has designed the thing to keep the number of pipeline stages low. Intel's design reaches higher clock speeds at the expense of work done per clock. To be honest, it's harder to get the thing to run at high clock speeds than it is to just add more execution units.
RTFA usually helps.... directly from the Conclusions section:
Although the Athlon 64 3500+ and the Xeon 3.6GHz EM64T processors were not necessarily designed to compete against each other, we found that comparing the two CPUs was more appropriate than anticipated, particularly in the light of Intel's newest move to bring EM64T to the Pentium 4 line. Once we obtain a sample of the Pentium 4 3.6F, we expect our benchmarks to produce very similar results to the 3.6 Xeon tested for this review.
Without a doubt, the 3.6GHz Xeon trounces over the Athlon 64 in math-intensive benchmarks. Intel came ahead in every severe benchmark that we could throw at it, particularly during John the Ripper. Even though John uses several different optimizations to generate hashes, in every case, the Athlon chip found itself at least 40% behind. Much of this is likely attributed to the additional math tweaking in the Prescott family core.
That's not to say that the Xeon CPU necessarily deserves excessive praise just yet. At time of publication, our Xeon processor retails for $850 and the Athlon 3500+ retails for about $500 less. Also, keep in mind that the AMD processor is clocked 1400MHz slower than the 3.6GHz Xeon. With only a few exceptions, the 3.6GHz Xeon outperformed our Athlon 64 3500+, whether or not the cost and thermal issues between these two processors are justifiable.
We will benchmark some SMP 3.6GHz Xeons against a pair of Opterons in the near future, so check back regularly for new benchmarks!
I don't understand your post at all. The Athlon line has historically been the better of the two (compared with Intel's P3 and P4 line) CPUs in FPU performance. In fact, the Athlon 64 and the Nocona both support x87, MMX, SSE, and SSE2 instruction sets.
There were other issues as well... These are some of the ones I saw where I was (I worked on clustering as well back then, we just got beaten to the published paper by them so they got the name). Here are some of the issues, in no particular order.
- many of the engineering and science centers were already very deep into the Unix workstation vendors and were used to the service, stability, and performance of the Unix boxes - Sun, SGI, HP, etc. Many of them didn't want PCs to come into the system because they would require lots of support (at the time back then, PCs were notorious for being maintenance issues with only one or two boxes, much less potentially 100s).
- 32-bit. Many codes ran on machines and expected large memory models (yes, even in distributed codes). The codes would have to be tweaked a bit to run in the smaller memory footprints.
- Performance in floating point. Back then, PCs weren't as fast as the Unix boxes. It wasn't until the PPro when the performance gap started closing/inverting. You could use 10 Suns or 20 PCs to get the performance. Of course, back to the logistics/support problem of any PC, much less 2X as many.
- Viable OSs. In 1995, Linux was still fairly fledgling. It worked, but there were lots of holes (feature holes and such). The only other alternative was to run a Windows variant. Neither really worked that well at the time. GCC on the x86 back then was pretty nasty too. On the same hardware in compute intensive code, we regularly saw 2X the performance on codes we compiled when running Windows with MSVC compared to the same hardware running Linux or Solaris (because of gcc).
- Reuse. Many centers used research money to buy new machines, which would then fold back into the infrastructure of the place when the research contract was over. As I mentioned before, they were already deep into the Unix workstations. Having a research project buying a bunch of PCs wouldn't eventually really improve the Unix workstations that they have in the place.
But just because in the *nix world things are done differently, and at the same time Windows users are to damn lazy to learn anything new,
./configure
You know... I can't remember a single episode of ST:TNG or ST:TOS or any other Sci-Fi show that portrays computers in the future where someone sits down at a terminal and types stuff like:
make
make install
I think computer interfaces have been trying to evolve for ease of use and removing as much of the workings from the hands of users as they can. It seems funny that the F/OSS community prides itself on being "future bound" so despirately clings to archaic typing and obscure character sequences to do things.
There are different definitions of the term: some (probably: most) apply to the USA, the more specific ones don't. However, most people usually deal with the more general terms and maybe are not even aware of the meaning of the more specific term. The burden of dealing with any ambiguity rests with those who are aware of the different meanings...
I'm just always reminded of those tests that say choose the most correct answer:
The USA is a(n):
a) Democracy
b) Democratic Republic
c) Communist State
d) Extra-terrestrial outpost
While "Democracy" is correct, it is correct in a general sense, much like instead of calling humans "Humans" or "persons" or whatever, we should just call them "organisms" or "entities" or even "mammals" or "animals" with supposedly the same amount of correctness.
As for b) I guess most people are well aware of that. It just begs the question whether this is a good thing or not. From an outsiders point of view, the presidential election system is very weird - for instance, the existance of states which de facto already belong to one or the other party, making the elections mostly a battle for the remaining borderline candidate states. (I apologise for any incorrect terminology.)
Not really... as begging the question means something else.
However, you have to ask whether this is a good or bad thing...
There are a few very good arguments for representative democracies. One of the main ones is to act as a buffer between the general populace and actual governmental policy. An example of this is that if something especially tragic happens, you don't have laws such as "evict all the Muslim folks" being passed by a simple majority of voters when supposedly the calmer heads of the elected officials can temper this a bit. Of course, many of the other reasons are for logistical reasons.
In my job (developer/management/etc), I am constantly typing in things, but never transcribing. Touch typing helps you when transcribing, because you can't easily look at the keyboard while transcribing. In modern jobs, transcription just isn't important. So I believe that my needing to look at the keyboard when typing does not hurt me at all. SPEED matters, but even more than that it is what you enter that matters!
Yeah... but as a touch typist, when I program, I'm not looking at the keyboard. I'm looking at what I type and the stuff around it. So instead of imagining what I want to type, then looking down at the keyboard and typing that, then looking up and thinking some more, I can literally spend all day typing without looking at the keyboard or stopping except to rest. In this mode, my ideas go from my head to the screen, while I'm absorbing whatever else information from the screen that I do while thinking.
When my mind is completely disengaged from the mechanics of getting the characters I want on the screen (i.e. I'm not looking at the keyboard at all and am just letting my thoughts flow from my head to the screen), I can really flow.
I guess this is where I differ from other folks. I don't necessarily like to use the mouse, and in fact, I use keyboard shortcuts a lot. To switch to the mouse, I have to disengage myself from thinking and hunt for the mouse. It's pretty astounding just how much time the mouse can take to use during the day. Of course, there are lots of things the mouse is very good at, so it speeds up lots of tasks so eventually, I think it's better to have a mouse than not. But I think the combination of using a single mode of input (keyboard) and only switching to the mouse when you'd really save time (not while programming hardly ever) is more productive (at least for me).
I think the folks who really thing speed matters are those who interrupt their thought processes to look down at the keyboard to type. In those cases, they have to make up for all the lost time thinking/analyzing while they are typing and jarring their thought processes so they can go back to looking and thinking about what they are doing. In those cases, speed is essential so you can burst the typing to get it out of the way. Most touch typist programmers don't need to type fast because they don't make many mistakes and they are thinking about what they are doing while they type instead of between typing microbursts.
In soviet russia the head of state was chosen by the party - in democratic America he's chosen by the supreme court.
It helps to study in grade school, especially in Civics class. a) the USA is NOT a Democracy. b) the American public does not choose the President directly by casting votes and those votes being counted for the ultimate result.
I'll leave it as an exercise for the reader to find out why my the above statements are true. You need to know why those statements are true in order to be able to discuss Presidential elections.
....
and what are your links to Apple and Microsoft and some book supposed to prove?
I can point to a book somewhere that will support anything I want to claim (can point to books that say the planet Earth is flat), but it doesn't make it true.
Quick summary: All of these installs were "out of the box" installs. I used to compile my kernel almost daily back in the 90s because it was fun and neat. I don't have the time for that anymore and much prefer stability and usability over sheer performance now.
Fedora Core 2:
Installation went OK.
I have a Geforce2MX200 video card (maybe MX400) and there were driver problems. Certain screen savers would lock the entire machine requiring a reset button hit. Overall, it was reasonable, but I didn't care too much for it. Stuff wasn't arranged very well from my standpoint in the menus and the like.
Mandrake 10 Professional:
Installation failures abound. Playing around one day after FC2 was installed, I was surprised that I could successfully install on a 20G partition that I made just to play with it some more. Eventually I figured out that a / partition larger than some value in the 20G range, it would fail install every time. A 20G / partition would install. I didn't like that, but I ran it that way for a couple days anyway. I liked Mandrake 10 Pro better than FC2 by a bit. Seemed to be a reasonably good distro other than the install issues.
SuSE 9.1 Professional:
Installation went OK.
I'm not as familiar with SuSE distros so some things are in odd places to me, but I can live with that. I eventually settled on this distro and run it currently. I figured it'd be fun to play around with a distro I wasn't as familiar with. I'm much more familiar with Mandrake and RedHat. Just a complete subjective feel of performance, not based on any real data, is that the SuSE is the fastest of the three, with Mandrake being close and FC2 being a ways behind. I'm sure some of it has to do with the stability and quality of the video drivers. So far, my SuSE install has been up for a month with no shut downs or anything.
If Mandrake could fix the 20G / install partition issue, I would probably have went with it all the way because of my familiarity with it. However, being as it is, SuSE seems to be the best of the three that I tried.
The problem is that Linux changes so fast that by the time any book is in print, it is outdated. Some stuff in it might be still good, but some things will no doubt be wrong (which will/can cause frustration if the person downloads the lastest version of the distro, which he/she will need to do to get the best support and bug fixes).
Could we then put a bunch of them in a big ball full of water with some small nativity type scene in it and shake it like a Snow Globe while it's running? :)
:)
:)
Or... how about putting a bubbler in there with something more viscous than water and watch it like a lava lamp?
Or... can I have them in my fish tank where I can watch the fish swim and compute at the same time?
Hell... 64-bit isn't ready yet in the Linux world either. It took me almost 2 months and 3 distros to get my AMD64 stable enough for everyday use.
The AMD64 running a 64-bit compiled binary is a 64-bit CPU. Addresses are 64-bit values (although only 40 bits are "honored" as far as the hardware goes right now). sizeof(long) == 8. etc. Doubles are still 64-bit, I don't think they do long double or anything like that (no 128-bit floats). The Intel 64-bit extention stuff is supposed to be binary ISA compatible with the AMD64 x86-64 ISA.
As far as other stuff, summaries of the AMD64 programming model can be found all over. There's probably one on ArsTechnica.
IP is only an issue if you make it an issue, which Australia seems want to do. But still there is hope for Europe and Asia who may yet still realize how much of a technological lead can be realized if they stick together and ensure their developers can create without having to fear being sued for something as silly as allowing a user to click once.
What evidence do you have that any technological lead can be had by ignoring IP? I'm not saying there can or can't be one, but I have never seen anything that would prove this assertion that so many people like to throw around as some irresputable truth. "Gut feel" and religious dogma are not sufficient proof.
Odd that 'harmonizing' is always in one direction - for some reason, no one ever wants to decrease IP regulation to harmonize with some other country.
Maybe it has something to do with making money as opposed to not making money. Remember, a company that has IP can generate jobs and make money for the government in the form of taxes. Removing IP and you just dropped the bottom out of that market, which may be profitable for developing countries.
The crux is this: we all bought in this phantom "Information Economy" in the 90's, completely bypassing the fact that the real money is made with SERVICES, not INFORMATION.
I would say that you got it backwards here. Anyone can do services. Few can produce information. Service industries make real money for the people who own the service companies. The people who work for service companies tend to be lower paid (McDonalds? BurgerKing? etc.) I know you'll say that in F/OSS that everyone owns their own company but the fact that there will be any number (perhaps many) people who can offer the service model to customers, the price for services will go down. It will be a buyers' market, not a sellers' market. In the end, the few medium-large companies will buy services from large companies (IBM, etc.) and the small companies will take all their software for free and not buy any (or very few) services.
Remember, when you pay for a boxed Linux distro, you are paying for the services that they packaged all the stuff up for you, and that you usually get like a year of service with it. If you aren't buying boxes at your work, then you are killing the service model that F/OSS so highly touts.
KDE looks beautiful, better than windows.
Completely subjective. I think KDE looks fairly asstastic, but it is better than Gnome and there's not much more choice for a reasonably featured GUI out of the box.
As far as GUIs go, I had KDE hang my machine 5 times today to the point where I had to power cycle. I haven't hung or crashed my Windows boxes in months/years.
But I guess that is their choice to make that tradeoff. I prefer proper multitasking, personally.
/. have no concept of users. Most users don't multitask. They sit down and do one thing at a time. Maybe they will push something to the background but rarely is it something that crunches (move Word to the background where it is waiting on the user to type something while they pull up an email reader to send email to someone).
And that is why most people in
As far as hanging the GUI, I had Mandrake 9.2 completely lock the system hardcore solid today 5 times. The cause? I clicked the Install Software thing too many times from the GUI. I was impatient and thought I had missed so I clicked again... then again... because the thing is so responsive... Then it got into some state where the only solution was to power cycle the machine.
There's another version of the 3200+ that is 2.2GHz and has the 512K L2 cache, which is the one that most people will be getting anyway.
Actually, I already do pay for (or contribute to) F/OSS organizations. I typically buy or contribute to applications that I think are written well and do a good job that I use. I also tend to pay for "boxed" versions of Linux distributions. In addition, I also write some F/OSS software. My previous post was with some bit of sarcasm, if you didn't notice.
I agree.
.sql files to do the right thing and your app runs. Your approach of embedding all the SQL leads to massive redevelopment for every RDBMS you support.
We are current migrating away from ms sql server. Since a lot of our app is written in Stored Procedures, a lot of the app has to be re written.
It's definately a mistake to put everything to stored procedures. Especially if you want to keep your app somewhat database independant.
This is completely false. One of the reasons TO use SPs is that you will be using multiple RDBMSs. You write your code (typically compiled code like C, C++, etc.) once and the stored procedures are written to "do the right thing" and each system returns a consistent result set or answer. That way you seperate your code from the implementation that is database specific.
If you are using embedded SQL in your code, every time you have to change a query, you have to recompile your entire app. Every time you want to port to a new RDBMS, you have to write a whole bunch of code to generate the right queries for you. At best, you designed your app from the start to see what RDBMS you are using then create an "object" that encapsulates all of your queries so they are isolated from your app. If you didn't do that, then every function you call that queries the database has to have if/else or switches to see which pathway to go down to get the right query.
Using Stored Procedures is what *keeps* your app database independent. As long as you are using real RDBMSs, you simply rewrite your
I'm betting that the reason you are down on SPs is that you are going to something that doesn't support SPs, like MySQL (I hope, instead of not just realizing you rewrite your SPs and your app runs as it is already compiled), which you had better understand the implications since you are going from an RDBMS to just a "data dumping place". There can be some things you aren't thinking of with your MySQL migration that can really, really ruin your day down the road if you don't watch it.
Yeah... don't pay for F/OSS... let's see how many people keep doing it when they realize they can't feed themselves or their family in that business. And then seen how many companies stay around to offer support for F/OSS and then see where Linux lives.