Yeah, I laugh at folks who complain about Microsoft Admin account and who also are proud of the fact they use sudo and open it up. It's easy to just write a trojan that does 'sudo' to install whatever it wanted.
Who says the service was 50% rendered? I can go to class, not pay attention, fail, and then claim it was the professor's responsibility to infuse me with the information so that I knew it.
Basically, you're saying that it is the professor's responsibility to plant the knowledge in your head in such a way that you understand it. I've taught senior level, split-level college classes. I cannot *make* you learn anything. I can expose you to the information using standard/reasonable teaching techniques but it is your responsibility to learn it. If you cannot grasp the information, then it is up to you to do what is necessary to have it presented in a way for you to understand. If that means coming to my office during office hours for discussions using different methods, that's fine. My door was always open and I stayed many hours past my posted hours (and hours not within my posted hours) helping students understand the subjects. Some students went from getting failing grades at midterms to passing with Bs (and once or twice even an A) by finals because they took it upon themselves to make use of my office hours to discuss the subjects they didn't understand in terms/methods they could deal with better.
Now, if the professor is really a poor teacher, then there is an issue. However, not having good classroom skills and/or being difficult do not mean that they aren't keeping their end of the bargain. Assigning arbitrary grades, inconsistent grading, and the like are, IMO.
'by porting software to Windows, we eliminate the majority of the competitive advantage of Free Software desktops in the eyes of the overwhelming majority of consumers while Microsoft has all the rope they need to shut the door once again on us... Free Software desktop applications on Windows represent a no-win situation for Open Source, but Open Source desktops on Free Software operating systems do.'
Is about as hypocritical as I've ever seen. Either you believe that F/OSS is Free and/or Open Source Software or you don't. If you do believe that it is Free/Open SS, then porting it to another platform is 'normal behavior'. If you think that porting the software to another platform eliminates 'the majority of the competitive advantage' then you have some other agenda to which you subscribe... but that agenda isn't about F/OSS...
Maybe because this is the company's internal IT practices, basically what they do to run their shop. He isn't talking about the product strategy groups who go off and do exactly what you are saying.
Wierd. I've worked on both open and closed source projects and I constantly feel that I have to prove myself and better myself. Otherwise, I just stagnate and have no reason to do anything well.
When you treat everything you do as if it must be done to the best of your ability, not only do you get good results but you also get respect from your peers and superiors. It doesn't matter whether the source is open or closed. It YOUR reputation on the line in either case. It's all about work ethic. What matters to me is that the code I write is stable and efficient. If you are one of the folks who always thinks about 'I'm not getting paid enough to do this' and the like, well... You've probably never felt the need (desire) to prove yourself anyway. Most of us who program (closed or open) do it because we'd do it even if we didn't get paid. Getting paid is just icing on the cake. For me, it means that I always have a project to work on (I run out of ideas and/or steam on my own ideas from time to time).
If that's the only qualification, every device driver ever written has to be included in the line and bug count. Also, pretty much any program that does anything interesting has to call into kernel space to have something done for it, so it's kind of running in kernel space too, just not all the time. Well... that pretty much pulls in every application ever written. I think that research group has a bit more work to do. If 5.7 million lines of code took them 5 years, they should only have about another 1000 years to go before they can publish:)
I'd mod you up if I could. Most people forget about this fact. How much do the cards cost per machine as well? Even if they were $100 each (I'm sure they are a bit higher), that'd add another $220K to the pricetag.
So, now we are up to around $8M (after a large discount from Apple). That's an increase in about 33% in just hardware. Any other company would have to pay people to install it.
Not to mention I haven't seen a satisfactory explanation of how they acquired all that Infiniband hardware which is expensive as well. The price they quote barely covers the XServes at a severe discount, much less anything else.
I agree with you to some degree, with some side notes:
Linux has probably done more to hurt that industry as help it. Sure, you have IBM and others dealing in Linux on their servers but all of those others that still exist are either gone or are so specialized that few/no new customers are coming to them.
As far as Sun, except for a few applications that are basically binary only Solaris, there's no real reason to buy a SPARC based machine today either. Linux + Intel/AMD has the basic workstation UNIX workstation market covered (and for much cheaper prices).
Most of the big server apps have migrated from a big SMP machine to a cluster of load balanced blades or the like (as you state). Blades and other load balanced clusters are easier to maintain and cheaper to buy initially.
The UNIX CPU vendors couldn't keep up with the commodity CPU vendor Intel (and AMD). As the Intel/AMD parts got faster, especially in FPU, there wasn't much need to buy the 10X more expensive 'workstation' CPUs any more. Look at all the CPU vendors and see what they are doing now: MIPS contracted to the embedded market. DEC gone. SPARC basically gone, just one CPU maker now. PA-RISC gone. Motorola is gone. Only IBM is really left making their CPUs (Power) and they are making the CPUs for Apple now too.
All/most of the important graphics design software was ported to Windows and Mac a long time ago when the CPUs there started to get into the neighborhood of processing speeds of the then workstation market. The PC Commodity market then killed the UNIX workstations. Even though the PCs weren't as fast as the UNIX workstations, they were "fast enough"... especially at 10% of the cost. Now, they are the fastest, partially because of the death of the UNIX CPUs but mostly because of the amount of money Intel (and AMD) put into research to make their CPUs faster.
The largest blow to the UNIX market though, IMO, was Linux. In order to have a UNIX-like platform, you no longer had to pay high prices for the OS license in addition to possibly high prices for the hardware if you had to have that as well (most of the time you did). With Linux, you could get the OS for free and use commodity PC hardware.
Yeah, much like getting health care from a doctor that isn't paid is good...
If you can't make a living as a programmer, you'll have several types of programmers: 1. Those that do it because they love it and can afford to not get paid. (the best case) 2. Those who do it when they can but still love it. They just have to fit it in with another job to make a living. (You wanted that patch fast?) 3. Those who wouldn't make money at it anyway.
The vast majority with be #2s. Basically, you'll have someone who has divided attentions and works when he can based on how tired he is from his paying job. Eventually, if coding consumes too much time, the project will be dropped or hopefully passed on to someone else who is most likely a #2.
Probably, the folks who have the most spare time to code are young folks who aren't married, have kids, etc. This isn't that bad, I guess, except for lack of experience. By the time you get married, buy a house, have kids, etc., you don't have the time to support a project as a full-time second job.
Actually, it used to be based solely on the width of the general purpose registers in the CPU, implying that the CPU could process data in those sizes with one ALU operation (the ALU was as wide as the general purpose registers).
The 68000 you mention was considered a 32-bit CPU, or at least a 32/16 (32-bit internally, 16-bit data bus) as was the 68010 and it wasn't until the 68020 when it had a 32-bit data bus as well. There was even a variant that was the 68008 that was identically equivalent to the 68000 except it had an 8-bit external data bus. I have occassionally seen the 68000 referred to as a 16-bit processor, but the vast majority of times I've seen it discussed call it a 32-bit CPU.
As far as I remember, no processor has ever been 'named' relative to the address bus width. Even in the PC world I can't remember any time when the CPUs were 'named' relative to the address bus. Many 32-bit CPUs didn't have the full 32-bit address bus externally accessible. I can't think of any 64-bit CPU that has the full 64-bit address bus externally accessible.
As far as cache storage of data, the data formats are independent of the pointer size. The blanket statement that a 64-bit CPU effectivly 'halves the cache' is not true. If you have a program that deals only with pointers, then you'd have a point but 'int' on a 64-bit CPU is the same as 'int' on a 32-bit CPU (both being 4 bytes or 32-bits). It *is* true that a program compiled for 64-bit ISA will use *some* more cache, but that is entirely dependent upon the program itself. Again, a program that uses pointers a lot may use more cache than the same code on a 32-bit architecture, but a program that uses few pointers may not use much more (if any more) than the 32-bit counterpart, depending upon the datatypes used.
Huh? What you say makes little sense. While it is true that smaller caches with less associativity respond faster, there is no "search through them more quickly" as it is all done in parallel. What makes it faster/slower is the depth of match logic required when you have many way set associativity (all the way up to fully associative which is the most expensive).
Secondly, why in the *world* would you not want to cache more data if you could? Ideally, all of your main memory would be just a large one-way set associative cache for best performance. (Compaq once made a 386 machine that had all SRAM as its main memory. No wait states at all and it was *fast* *fast* but it was also *expensive* *expensive* and upgrades for the memory were incredibly expensive.)
I'm thinking that this post must have been a failed attempt at humor.
a) the 64-bit CPUs that exist today have 32-bit instructions. 2) just because the width of the registers is 64-bit does not mean that all data that is processed is now 64-bit wide, 64-bit CPUs are certainly capable of processing 32-bit values. D) somehow having a value stored as 64-bits doesn't mean you can use it for twice as many things as the same value stored as 32-bits (assuming it fits) or somehow all of your programs/algorithms can use the value twice as much as before (implying twice the work)
That is why you need to stay away from all the bad games. Only play on 100%+ payback systems or play where the house don't have the advantage.
Well... if many games have those kinds of payback then casinos wouldn't be in business long. The first rule of casinos is to make money. There are a couple of games where the house doesn't have an advantage but that doesn't mean that the game >= 100% payback.
I believe the HAL still exists. To improve video speed, the graphics subsystem was moved into kernel space from user space some time ago. The A21164PC wasn't as good as the A21164A. The A21164PC was basically the A with a half sized data bus to make it cheaper so as to try to push into a cheaper workstation market.
Unfortunately, Digital's methods of working on the Alpha couldn't be sustained because they were too costly. Hand optimization of processors was too lengthy (costly) and they didn't use bin sorting on their wafers in order to get the highest speed rated parts they could. Again, this involved a lot of work (costly).
The Alpha was a really neat processor but it was destined from the get-go to be a sidenote in history.
My error. I didn't make paragraphs where I needed them in that section. Here it is edited. I tried to mark the places where I changed things in []s:
Also, as I said before and you affirmed, MySQL does do a great job for certain types of applications, several of which you mention.
However, one of the scary things [] I [have witnessed is that] people use [MySQL as a solution where it lacks the proper features to solve the problem]. In the end, the work that these people do reflects badly upon the OSS work because [employers new to OSS will say]: "Yeah, we hired some bozos to write some OSS stuff for us and we lost several clients' information and somehow a number of orders 'disappeared' from the database."
It's not that you can't make the same mistakes in other RDBMSs, but [there are] people who don't know what they are doing, but think they do, recommend[ing] the wrong tools for the [] job while posing as experts. I've found that people who poo-poo transactions as being 'unnecessary overhead' tend to not understand what transactions are for, when to use them, and why/when they've made bad choices in the past when designing systems [using MySQL or any other RDBMS without using transactional processing even when available].
Thanks for posting a good reply. One thing you mentioned:
To put it in crude terms, anything that can implement the most basic SQL select with an inner join is an RDBMS.
I guess drew my attention. RDBMSs also have features that insure referential integrity, not just that you can do a JOIN... i.e. you can't insert that record because the value you have for fForKey is not in the set of values that exist in KeyTable.fPriKey. Similarly, you can't delete the record in KeyTable because a record in OtherTable still contains a reference to the record in KeyTable.
On a different note, there are issues about other features, such as triggers, which can make calculations inside a transaction block more effient than multiple transfers from a client to synthesize it, that I haven't seen discussed well. Not that I use triggers often, it's just an example.
Also, as I said before and you affirmed, MySQL does do a great job for certain types of applications, several of which you mention, but one of the scary things is when I see people use it to address problems that the lack of support in MySQL may cause issues. In the end, the work that these people do reflects badly upon the OSS work because you'll get folks saying stuff like: "Yeah, we hired some bozos to write some OSS stuff for us and we lost several clients' information and somehow a number of orders 'disappeared' from the database." It's not that you can't make the same mistakes in other RDBMSs, but it's that people who don't know what they are doing, but think they do, recommend the wrong tools for the wrong job while posing as experts. I've found that people who poo-poo transactions as being 'unnecessary overhead' tend to not understand what transactions are for, when to use them, and why/when they've made bad choices in the past when designing systems.
Slashdot Mirror
Well... that *was* about a year and a little over a month ago. Maybe *this* year is the year of LOTD!
(You know, for some reason every time I see LOTD, I think it is somehow related to LOTR.)
# in a perfect world this would increse my karma
$karma++;
No... that would be "in a Perlfect world..."
Yeah, I laugh at folks who complain about Microsoft Admin account and who also are proud of the fact they use sudo and open it up. It's easy to just write a trojan that does 'sudo' to install whatever it wanted.
Are you saying that in this commune, one man has the right to rule because some watery tart flung a sword at him?
Who says the service was 50% rendered? I can go to class, not pay attention, fail, and then claim it was the professor's responsibility to infuse me with the information so that I knew it.
Basically, you're saying that it is the professor's responsibility to plant the knowledge in your head in such a way that you understand it. I've taught senior level, split-level college classes. I cannot *make* you learn anything. I can expose you to the information using standard/reasonable teaching techniques but it is your responsibility to learn it. If you cannot grasp the information, then it is up to you to do what is necessary to have it presented in a way for you to understand. If that means coming to my office during office hours for discussions using different methods, that's fine. My door was always open and I stayed many hours past my posted hours (and hours not within my posted hours) helping students understand the subjects. Some students went from getting failing grades at midterms to passing with Bs (and once or twice even an A) by finals because they took it upon themselves to make use of my office hours to discuss the subjects they didn't understand in terms/methods they could deal with better.
Now, if the professor is really a poor teacher, then there is an issue. However, not having good classroom skills and/or being difficult do not mean that they aren't keeping their end of the bargain. Assigning arbitrary grades, inconsistent grading, and the like are, IMO.
I agree... this statement:
... Free Software desktop applications on Windows represent a no-win situation for Open Source, but Open Source desktops on Free Software operating systems do.'
'by porting software to Windows, we eliminate the majority of the competitive advantage of Free Software desktops in the eyes of the overwhelming majority of consumers while Microsoft has all the rope they need to shut the door once again on us
Is about as hypocritical as I've ever seen. Either you believe that F/OSS is Free and/or Open Source Software or you don't. If you do believe that it is Free/Open SS, then porting it to another platform is 'normal behavior'. If you think that porting the software to another platform eliminates 'the majority of the competitive advantage' then you have some other agenda to which you subscribe... but that agenda isn't about F/OSS...
Maybe because this is the company's internal IT practices, basically what they do to run their shop. He isn't talking about the product strategy groups who go off and do exactly what you are saying.
Wierd. I've worked on both open and closed source projects and I constantly feel that I have to prove myself and better myself. Otherwise, I just stagnate and have no reason to do anything well.
When you treat everything you do as if it must be done to the best of your ability, not only do you get good results but you also get respect from your peers and superiors. It doesn't matter whether the source is open or closed. It YOUR reputation on the line in either case. It's all about work ethic. What matters to me is that the code I write is stable and efficient. If you are one of the folks who always thinks about 'I'm not getting paid enough to do this' and the like, well... You've probably never felt the need (desire) to prove yourself anyway. Most of us who program (closed or open) do it because we'd do it even if we didn't get paid. Getting paid is just icing on the cake. For me, it means that I always have a project to work on (I run out of ideas and/or steam on my own ideas from time to time).
If that's the only qualification, every device driver ever written has to be included in the line and bug count. Also, pretty much any program that does anything interesting has to call into kernel space to have something done for it, so it's kind of running in kernel space too, just not all the time. Well... that pretty much pulls in every application ever written. I think that research group has a bit more work to do. If 5.7 million lines of code took them 5 years, they should only have about another 1000 years to go before they can publish :)
Where's your $1.4M for the Mellanox donated Infiniband switches (each of which is $58K)?
Where's your additional cost for the 1100 Infiniband cards that are in each box? (They aren't cheap either.)
I'd mod you up if I could. Most people forget about this fact. How much do the cards cost per machine as well? Even if they were $100 each (I'm sure they are a bit higher), that'd add another $220K to the pricetag.
So, now we are up to around $8M (after a large discount from Apple). That's an increase in about 33% in just hardware. Any other company would have to pay people to install it.
Not to mention I haven't seen a satisfactory explanation of how they acquired all that Infiniband hardware which is expensive as well. The price they quote barely covers the XServes at a severe discount, much less anything else.
I agree with you to some degree, with some side notes:
Linux has probably done more to hurt that industry as help it. Sure, you have IBM and others dealing in Linux on their servers but all of those others that still exist are either gone or are so specialized that few/no new customers are coming to them.
As far as Sun, except for a few applications that are basically binary only Solaris, there's no real reason to buy a SPARC based machine today either. Linux + Intel/AMD has the basic workstation UNIX workstation market covered (and for much cheaper prices).
Most of the big server apps have migrated from a big SMP machine to a cluster of load balanced blades or the like (as you state). Blades and other load balanced clusters are easier to maintain and cheaper to buy initially.
The UNIX CPU vendors couldn't keep up with the commodity CPU vendor Intel (and AMD). As the Intel/AMD parts got faster, especially in FPU, there wasn't much need to buy the 10X more expensive 'workstation' CPUs any more. Look at all the CPU vendors and see what they are doing now: MIPS contracted to the embedded market. DEC gone. SPARC basically gone, just one CPU maker now. PA-RISC gone. Motorola is gone. Only IBM is really left making their CPUs (Power) and they are making the CPUs for Apple now too.
All/most of the important graphics design software was ported to Windows and Mac a long time ago when the CPUs there started to get into the neighborhood of processing speeds of the then workstation market. The PC Commodity market then killed the UNIX workstations. Even though the PCs weren't as fast as the UNIX workstations, they were "fast enough"... especially at 10% of the cost. Now, they are the fastest, partially because of the death of the UNIX CPUs but mostly because of the amount of money Intel (and AMD) put into research to make their CPUs faster.
The largest blow to the UNIX market though, IMO, was Linux. In order to have a UNIX-like platform, you no longer had to pay high prices for the OS license in addition to possibly high prices for the hardware if you had to have that as well (most of the time you did). With Linux, you could get the OS for free and use commodity PC hardware.
We got a ticket like this once, but it was used to emphasize the point:
c au sethespacebardoesn'tworkanymore.
wouldyoupleasereplacethekeyboardonthismachinebe
Yeah, much like getting health care from a doctor that isn't paid is good...
If you can't make a living as a programmer, you'll have several types of programmers:
1. Those that do it because they love it and can afford to not get paid. (the best case)
2. Those who do it when they can but still love it. They just have to fit it in with another job to make a living. (You wanted that patch fast?)
3. Those who wouldn't make money at it anyway.
The vast majority with be #2s. Basically, you'll have someone who has divided attentions and works when he can based on how tired he is from his paying job. Eventually, if coding consumes too much time, the project will be dropped or hopefully passed on to someone else who is most likely a #2.
Probably, the folks who have the most spare time to code are young folks who aren't married, have kids, etc. This isn't that bad, I guess, except for lack of experience. By the time you get married, buy a house, have kids, etc., you don't have the time to support a project as a full-time second job.
heh... from Home Alone, that older bully kid used it somewhere, I thought it was funny, and it stuck ;)
Actually, it used to be based solely on the width of the general purpose registers in the CPU, implying that the CPU could process data in those sizes with one ALU operation (the ALU was as wide as the general purpose registers).
The 68000 you mention was considered a 32-bit CPU, or at least a 32/16 (32-bit internally, 16-bit data bus) as was the 68010 and it wasn't until the 68020 when it had a 32-bit data bus as well. There was even a variant that was the 68008 that was identically equivalent to the 68000 except it had an 8-bit external data bus. I have occassionally seen the 68000 referred to as a 16-bit processor, but the vast majority of times I've seen it discussed call it a 32-bit CPU.
As far as I remember, no processor has ever been 'named' relative to the address bus width. Even in the PC world I can't remember any time when the CPUs were 'named' relative to the address bus. Many 32-bit CPUs didn't have the full 32-bit address bus externally accessible. I can't think of any 64-bit CPU that has the full 64-bit address bus externally accessible.
As far as cache storage of data, the data formats are independent of the pointer size. The blanket statement that a 64-bit CPU effectivly 'halves the cache' is not true. If you have a program that deals only with pointers, then you'd have a point but 'int' on a 64-bit CPU is the same as 'int' on a 32-bit CPU (both being 4 bytes or 32-bits). It *is* true that a program compiled for 64-bit ISA will use *some* more cache, but that is entirely dependent upon the program itself. Again, a program that uses pointers a lot may use more cache than the same code on a 32-bit architecture, but a program that uses few pointers may not use much more (if any more) than the 32-bit counterpart, depending upon the datatypes used.
I agree... I was reading that and thought I was on acid or something.
Huh? What you say makes little sense. While it is true that smaller caches with less associativity respond faster, there is no "search through them more quickly" as it is all done in parallel. What makes it faster/slower is the depth of match logic required when you have many way set associativity (all the way up to fully associative which is the most expensive).
Secondly, why in the *world* would you not want to cache more data if you could? Ideally, all of your main memory would be just a large one-way set associative cache for best performance. (Compaq once made a 386 machine that had all SRAM as its main memory. No wait states at all and it was *fast* *fast* but it was also *expensive* *expensive* and upgrades for the memory were incredibly expensive.)
I'm thinking that this post must have been a failed attempt at humor.
There's so many things wrong with this post...
a) the 64-bit CPUs that exist today have 32-bit instructions.
2) just because the width of the registers is 64-bit does not mean that all data that is processed is now 64-bit wide, 64-bit CPUs are certainly capable of processing 32-bit values.
D) somehow having a value stored as 64-bits doesn't mean you can use it for twice as many things as the same value stored as 32-bits (assuming it fits) or somehow all of your programs/algorithms can use the value twice as much as before (implying twice the work)
That is why you need to stay away from all the bad games. Only play on 100%+ payback systems or play where the house don't have the advantage.
Well... if many games have those kinds of payback then casinos wouldn't be in business long. The first rule of casinos is to make money. There are a couple of games where the house doesn't have an advantage but that doesn't mean that the game >= 100% payback.
I believe the HAL still exists. To improve video speed, the graphics subsystem was moved into kernel space from user space some time ago. The A21164PC wasn't as good as the A21164A. The A21164PC was basically the A with a half sized data bus to make it cheaper so as to try to push into a cheaper workstation market.
Unfortunately, Digital's methods of working on the Alpha couldn't be sustained because they were too costly. Hand optimization of processors was too lengthy (costly) and they didn't use bin sorting on their wafers in order to get the highest speed rated parts they could. Again, this involved a lot of work (costly).
The Alpha was a really neat processor but it was destined from the get-go to be a sidenote in history.
Heh, your first computer had an almost 2X higher clock speed than mine and your disk drive had 4X the memory :)
1MHz w/ 4K RAM.
My error. I didn't make paragraphs where I needed them in that section. Here it is edited. I tried to mark the places where I changed things in []s:
Also, as I said before and you affirmed, MySQL does do a great job for certain types of applications, several of which you mention.
However, one of the scary things [] I [have witnessed is that] people use [MySQL as a solution where it lacks the proper features to solve the problem]. In the end, the work that these people do reflects badly upon the OSS work because [employers new to OSS will say]: "Yeah, we hired some bozos to write some OSS stuff for us and we lost several clients' information and somehow a number of orders 'disappeared' from the database."
It's not that you can't make the same mistakes in other RDBMSs, but [there are] people who don't know what they are doing, but think they do, recommend[ing] the wrong tools for the [] job while posing as experts. I've found that people who poo-poo transactions as being 'unnecessary overhead' tend to not understand what transactions are for, when to use them, and why/when they've made bad choices in the past when designing systems [using MySQL or any other RDBMS without using transactional processing even when available].
Thanks for posting a good reply. One thing you mentioned:
To put it in crude terms, anything that can implement the most basic SQL select with an inner join is an RDBMS.
I guess drew my attention. RDBMSs also have features that insure referential integrity, not just that you can do a JOIN... i.e. you can't insert that record because the value you have for fForKey is not in the set of values that exist in KeyTable.fPriKey. Similarly, you can't delete the record in KeyTable because a record in OtherTable still contains a reference to the record in KeyTable.
On a different note, there are issues about other features, such as triggers, which can make calculations inside a transaction block more effient than multiple transfers from a client to synthesize it, that I haven't seen discussed well. Not that I use triggers often, it's just an example.
Also, as I said before and you affirmed, MySQL does do a great job for certain types of applications, several of which you mention, but one of the scary things is when I see people use it to address problems that the lack of support in MySQL may cause issues. In the end, the work that these people do reflects badly upon the OSS work because you'll get folks saying stuff like: "Yeah, we hired some bozos to write some OSS stuff for us and we lost several clients' information and somehow a number of orders 'disappeared' from the database." It's not that you can't make the same mistakes in other RDBMSs, but it's that people who don't know what they are doing, but think they do, recommend the wrong tools for the wrong job while posing as experts. I've found that people who poo-poo transactions as being 'unnecessary overhead' tend to not understand what transactions are for, when to use them, and why/when they've made bad choices in the past when designing systems.