Yes, wrappers or layers are just a type of abstraction/encapsulation... and you always have to be careful when creating new abstractions. (See "Leaky abstractions" etc.)
What I was saying about wrappers for wrappers was meant to be just sort of a joke... pointing out the fact that if you are making a wrapper around some standard tool to tailer it for your own use, you have no idea what that tool is in fact a wrapper around, itself. Just the irony of building a black box around a black box creating a new black box... and while thinking about that you have to wonder about what's inside the box inside of yours (was that inoherent? probably). China dolls? Who knows. Anyway... now I'm just rambling.
The point of talking about layers is simply to address the concern raised further up the thread that people can't reuse code because it is either too general, or too specific (for something else). Wrappers are a good way to make a general tool into a tool that is specific for your purposes... and it is often easy to create a simple but robust wrapper that just makes a general tool more useful. Some simple (possibly over simple) analogies are shell scripts ad aliases. Think about what you are doing with these... you're just taking powerful tools and tailering them to the particular use-cases that you want them for.
Or here is (probably) a much better example: XML parsers. A truly compliant XML parser is an incredible pain in the ass to a typical application developer, because it leaves far too much work for the developer. How often does a developer simply want to use an XML parser/generator simply for serialization/deserialization of complex data objects? (I know that I do this all the damn time.) What you need is not a powerful, compliant XML parser, but a nice little wrapper around one that does everything you need and nothing you don't. Of course, different projects may have different notions of what is necessary and what isn't... hence you end up making your own wrapper around a very general tool... then you end up using that wrapper all over your code.
Put too many glue layers in and whoever has to maintain that code is either going to cry or hunt you down and kill you.
Oh, that's absolutely true... I was replying more to the general notion that slow code is bad code (as a general rule). The whole point was about total cost, and the oft-quoted figure is that there is about a 10 to 1 ratio of development work to maintenance work on any body of software... so you certainly don't want to sell out maintenance costs to development costs. The flip side to that, though, is that there is frequently much higher *opportunity cost* to development than to maintenance... the rush to market, and hence the need for rapid prototyping. How many businesses failed because they were trying to write their code in the "right way" instead of the "right now" way... only to find that before they had finished, some competitor whose system was held together with spit and duct-tape had pulled off a land-grab. If you're an MBA-type, you can probably assign some sort of dollar-value to that stuff, and then compare it against maintenance costs...
...and to make a long story short, that's why I program primarily in perl these days!:-D
Yeah, but one of the ironies of software development in this day and age is the concept of total cost:
It used to be the computation cycles were incredibly expensive things, and programmer work-hours were relatively inexpensive in comparison (well... I don't mean literally cycles compared to hours... but say billions of cycles compared to hours or some such). Of course, in today's world, the time of a *good* programmer can be fairly expensive, whereas big fast computers are fairly cheap. When you look at the total cost to do develop and run and maintain a software system over its lifetime, you begin to see an advantageous trade-off emerge. Quicker time to develop and easier maintenance, even at the cost of a significant degredation in application performance (within reason, of course) is a REALLY GOOD DEAL. It's not about laziness, it's economics of the simplest sort: all things being equal, lower costs (total costs, of course).
Anyway, this is nothing new or insightful... but it is apropos to the comment.
This is honestly very often the case. I think that the best comprimise (from my own experience) is to take overly-flexible packages and write your own middle-layer that glues together the powerful but too flexible to be useful code with your own specific needs.
Of course, the humor is that you find yourself writing wrapper layers for wrapper layers.
What the hell? I would mod you off topic if I had mod points. Some people _are_ going for a CS PhD...why can't they have stories, too? Besides, this isn't on the front page, and obviously only a few people are reading it, anyway. Cut 'em some slack.
Where are my mod points when I need them... seriously. I am sick of hearing people say that RDBMSs are crap or whatever because they can't deal with the fact that DOING HARD STUFF IS HARD.
In the development of a transactional processing system, once the volume of data becomes large and the needs for data integrity and manageability becomes overwhelming... you had soooo better be using a relational database. Object databases just aren't suited for the kind of work that is really important to the majority of applications (unless, at least, the object database is really just an access layer on top of a relational database).
Well, alright, I messed up saying Apache. Sorry. The point remains though... if there were GPL'd code inside my banks ATM, would they have to give me the source? The question is: if someone is accessing a GPL'd aplication that is being operated by another party, would the GNU folks' lawyers try to force the operators to give make their source code available? I wouldn't think so, myself, but the legalese can be kind of fuzzy. There are certainly many companies out there who are running GPL-based servers of some sort without any expectation of haing to open up their source.
OK, but there's a slippery slope here. I'm actually kind of familiar with salesforce.com (although not favorably), and they don't really lease the software, they lease the use of their service. So, if you have made software based on Apache, let's say, and you charge people to access your servers... are you "distributing" Apache? Must you provide the source to your servers?
Well, ok... here is what I do/what my home network looks like... admittedly its very similar to what you describe:
cable modem
|
|
linux router ---- wireless LAN
|
|
wired LAN
(that is a linux router sitting between three different networks (three NICs in the router))
On the WAP I'm running max WEP encryption (128 bits). I don't bother to do MAC filtering because MAC could be spoofed *far* more easily than cracking the WEP key. I know that WEP is not a great security protocol, but it is not completely ineffective, either. At the very least, it will slow down an attacker. (Also, there's the fact that there are at least 3 wide-open WLANs in the imediate vicinity: "If you and a friend are being chased by a bear... you don't have to be faster than the bear, just faster than your friend".)
The linux router runs dhcp for both the wired and wireless LANs. It runs FreeS/WAN (free linux IPSec gateway). I use iptables to perform NAT (I only have one real IP address, so the two internal subnets use imaginary IPs) to the cable modem.
I also use iptables on the linux router to enforce simple firewall rules. Inbound new (and not "related") connections from the cable modem are blocked except to allowed services (http and ssh). Apart from dhcp, only ipsec traffic is forwarded from the wireless LAN.
From my laptop (about the only user of the wireless LAN), I use win2k's ipsec (stupid pain in the ass to configure).
Yes, FM radio is on tall towers, but not tall enough to clear the horizon. FM radio does "bend" (diffract, really) around the horizon. The reason to put it on tall towers is that it does not have an infinite capacity to bend around the horizon. So by putting it on a tall tower, you can still go further than without. Seriously... get out a pair of binoculars. Do you see the radio tower? No, you don't.
Certainly this has too high of a frequency to gain a whole lot of benefit from difraction around the horizon, but it's not zero, either. Also, you'll note that 802.16, at least currently, can operate in a lot of different ranges of the RF spectrum, so I'm not even going to go through the bother of trying to figure out how much or how little it can bend. The definitive answer is: not a whole lot, but ot zero. Period.
FYI: not going from the marketing blurb. Going from the 802.16 specification that got posted here several weeks ago. Oh, that and a couple physics degrees (though I've been out of the field for a while). Not trying to sound high and mighty; the typical amateur radio enthusiast would know a lot more about the specifics than me. Still, it takes a real man to make a few random insults and unsupported FUD claims as AC. Good for you.
What a shocking number of people seem to be missing is that these are for different purposes! It's like asking why the roads have both cars and trucks on them.
The 802.11's are for wireless LAN. Local area net. They are a replacement for/supplement to ethernet. The various sub-standards do differ, that's true... but they are to serve different purposes (different levels of trade-off in price/range/throughput), and as far as interoprablity goes, that is supposed to be one of the purposes of 802.11g.
802.16 is for wireless MAN. Metropolitan Area Network. That is actually somewhat of a new concept. It is something like a replacement for cable modem/DSL or for T1's, but it's not really the same as either. It is supposed to be a cheaper form of high throughput last-mile delivery.
Despite many very cool attempts made over the past year or two, 802.11 is not particularly suited to delivering the last mile. It's fundamentally only good for a small number of computers over a short distance. That's a fact about the construction of the media access control layer and the radio spectrum. However, it does make for a much cheaper and easily configurable network. You wouldn't want to waste the money on more expensive radio equipment and spectrum in order to carry signals over a mere hundred feet to a handful of computers if you can do it cheaply and easily without.
Anyway, I think that 802.16 is just tremendously cool. Cable modems are neat and all, but anything to increase the competition in the last-mile space is great. Another thing that I would really like to see come about is a grassroots mesh network of 802.11. Just simple folk who share their cable modems with one another. You can route to mine if I can route to yours. That sort of thing. Anyway... getting off topic.
No, no, no. They explicitly said that this does *not* require line of site. Electromagnetic wave propogation is not all like visible light (line of site). Depending on the wavelengths involved, electromagnetic radiation can "bend" significantly. Think about it: do you have a line of site with the antenna tower of your favorite FM radio station? No. What about AM radio? Hell, the low frequencies used in AM can carry hundreds of miles without even factoring in the effect of reflection off the ionosphere.
Anyway, the point is that this is not something that requires an antenna to "hold the beam up" above the horizon.
Why does Fox have to cancel all its good shows?
on
Firefly Coming to DVD
·
· Score: 4, Insightful
It's really very sad and disturbing. Fox honestly seems to develop some of the best and most original shows that hit TV these days, along with some of the absolute worst crap. Why do they nearly always choose the crap over the good stuff?
Firefly is a great example. Do I have to mention Futurama? What about Andy Richter being taken off the air for this godawful crap "The Pits"?
Well, I'm not saying "engineering bad" or any such nonsense. I just mean to say that what people generally refer to as "software engineering", in practice, is about making programming into an assembly line. It arrises from one fundamental difference between software production and any other kind of industry... and that is that there is nothing really separating the prototype from the product.
You see business people (classicaly) thought of their engineers as the people designing the product and their manufacturers as the people producing the product. They could, grudgingly, separate the two notions. However, in software, the design *is* the product, like in architecture, for example. However, big business thought processes are very invested in the notion of the assembly line. Thus, they start to see their programmers as the assembly line instead of the engineers (in the clasic sense of the product designers).
Anyway, that's the notion I was delving into. There is certainly real engineering involved in creating software, but the business term "software engineering" carries some heavy connotations of turning programmers into cogs.
Software Engineering is different in Purpose
on
Software Craftsmanship
·
· Score: 4, Interesting
Contrary to what the author of this review is saying, I really do think that software engineering is different from software craftsmanship. Although you can take many of the things said about software engineering and come up with an application of them similar to an application you could come up with for software craftsmanship, but in practice you wouldn't. This is because the underlying philosophies are very different, and they exist for different purposes. The philosophies/purposes break down like this:
Software Engineering: make the development of software a controllable business process.
Software Craftsmanship: make the best software.
The basic notion of software engineering is to create a *process* which is so perfect that no personal weaknesses in your programmers can hurt the company. A subtle side effect of this is that it also tends to prevent any extremely great individual contribution from having a large impact. That is, the goal is to make all of your coders cogs in a machine. The business owners and managers would much rather have this setup because it makes it easier for them to sleep at night.
Well, the biggest difference has got to be that the two are built for completely different purposes.
BIND is a general purpose name server for use anywhere in the hierarchical dns scheme. That is, in simplest terms, it accepts requests from below, and either serves them or passes the query up (hierarchy = tree).
NSD, according to what is being said is for *authoritative servers only*. That is, it only serves requests, it never passes them up (because it only runs at the nood nodes). It may be true that they intend to make it a general purpose name daemon in the future, but at least for right now, it just simply does not do all of the different things that bind does. One might guess that, because it does fewer things, it does them better, but I sure as hell don't know that to be the case.
I don't expect linux to be less ugly about it on 32bit architecture. I was talking about the upcoming 64 bit architecture.
The current hardware doesn't really allow for >32bit addressing in a graceful way. The article is partly about the growing support for future (near future) 64bit x86 architecture, and I was saying that I liked it. I was citing the possibility of (hopefully) having better memory addressing as part of why, I'm looking forward to it. Last, I was just saying that I can't wait for linux to support this new capability. See the other thread, and Rellik apparently has some stories about the work that has already been done on linux under the (not yet released) 64bit x86 arch.
1. They don't do it yet (how could they? the hardware isn't really out there yet)
2. I think there's a good chance that they will do it soon. Your example only goes along with that.
I'm sorry, but I can't accept the argument that "linux already does 64 bit memory addressing on other architectures, so that means that they already do it on x86 architecture". That doesn't exactly make sense. There are separate bits of code there, so it's not automaticaly done yet. It does mean that, again, hopefully it shouldn't take long.
There are a couple of issues:
1. I'm not going to put it on my servers until it's actually been released and tested. Mostly because my bosses wouldn't let me put it out until it had been (for example) Oracle certified.
2. Even if they have done some demos on pre-release hardware, that's not the same thing as having it done and released
Anyway, I think you must have misunderstood me. Either that or I misunderstood you, or you're just trying to make an argument out an apparent agreement so that we get mod'ed as interesting:-P
Ah. Must have misunderstood you, then. Thought you were saying that you couldn't see linux on Intel / AMD as possibly dominating the server market. And I didn't mean to say that they necessarily would, either... just that it seems an interesting possibility.
Pardon me... You are correct. What I should have said was:
Good support for more than 4 gigs of ram on x86 architecture. Also note that I said "good" support, not just some crappy hack. I'm pretty sure that hasn't yet come to pass... but I'd be happy to be wrong, I guess.
Don't get me wrong, I don't think this is gonna take terribly long (and I sure hope it doesn't).
I don't know that it is so unreasonable to imagine the future of servers based on Intel and AMD running linux. Just look at how much ground theyve covered recently. What is silly is the notion that that doesn't leave room for folks like IBM, and maybe Sun. After all, there is a lot more to a server than just a processor and a free O/S kernel. Personally, I'm kind of taken with the way that (big bad) IBM has been pushing x86 and linux on the small to medium (and growing) end server.
True, linux on x86 is not big iron... yet... but do you relly mean to discount the possibility that it could become a cheaper solution to big iron? For one example, look at Oracle RAC on x86 blades. It's not exactly one megalythic server... it's really more like a beowulf cluster, actually... but what works works.
Anyway... it'll be intersting to see how this all plays out.
Slashdot Mirror
Yes, wrappers or layers are just a type of abstraction/encapsulation... and you always have to be careful when creating new abstractions. (See "Leaky abstractions" etc.)
What I was saying about wrappers for wrappers was meant to be just sort of a joke... pointing out the fact that if you are making a wrapper around some standard tool to tailer it for your own use, you have no idea what that tool is in fact a wrapper around, itself. Just the irony of building a black box around a black box creating a new black box... and while thinking about that you have to wonder about what's inside the box inside of yours (was that inoherent? probably). China dolls? Who knows. Anyway... now I'm just rambling.
The point of talking about layers is simply to address the concern raised further up the thread that people can't reuse code because it is either too general, or too specific (for something else). Wrappers are a good way to make a general tool into a tool that is specific for your purposes... and it is often easy to create a simple but robust wrapper that just makes a general tool more useful. Some simple (possibly over simple) analogies are shell scripts ad aliases. Think about what you are doing with these... you're just taking powerful tools and tailering them to the particular use-cases that you want them for.
Or here is (probably) a much better example: XML parsers. A truly compliant XML parser is an incredible pain in the ass to a typical application developer, because it leaves far too much work for the developer. How often does a developer simply want to use an XML parser/generator simply for serialization/deserialization of complex data objects? (I know that I do this all the damn time.) What you need is not a powerful, compliant XML parser, but a nice little wrapper around one that does everything you need and nothing you don't. Of course, different projects may have different notions of what is necessary and what isn't... hence you end up making your own wrapper around a very general tool... then you end up using that wrapper all over your code.
Oh, that's absolutely true... I was replying more to the general notion that slow code is bad code (as a general rule). The whole point was about total cost, and the oft-quoted figure is that there is about a 10 to 1 ratio of development work to maintenance work on any body of software... so you certainly don't want to sell out maintenance costs to development costs. The flip side to that, though, is that there is frequently much higher *opportunity cost* to development than to maintenance... the rush to market, and hence the need for rapid prototyping. How many businesses failed because they were trying to write their code in the "right way" instead of the "right now" way... only to find that before they had finished, some competitor whose system was held together with spit and duct-tape had pulled off a land-grab. If you're an MBA-type, you can probably assign some sort of dollar-value to that stuff, and then compare it against maintenance costs...
Yeah, but one of the ironies of software development in this day and age is the concept of total cost:
It used to be the computation cycles were incredibly expensive things, and programmer work-hours were relatively inexpensive in comparison (well... I don't mean literally cycles compared to hours... but say billions of cycles compared to hours or some such). Of course, in today's world, the time of a *good* programmer can be fairly expensive, whereas big fast computers are fairly cheap. When you look at the total cost to do develop and run and maintain a software system over its lifetime, you begin to see an advantageous trade-off emerge. Quicker time to develop and easier maintenance, even at the cost of a significant degredation in application performance (within reason, of course) is a REALLY GOOD DEAL. It's not about laziness, it's economics of the simplest sort: all things being equal, lower costs (total costs, of course).
Anyway, this is nothing new or insightful... but it is apropos to the comment.
Holy crap! Do I have a fan-club or something? That talk sounds awfully familiar.
This is honestly very often the case. I think that the best comprimise (from my own experience) is to take overly-flexible packages and write your own middle-layer that glues together the powerful but too flexible to be useful code with your own specific needs.
Of course, the humor is that you find yourself writing wrapper layers for wrapper layers.
What the hell? I would mod you off topic if I had mod points. Some people _are_ going for a CS PhD...why can't they have stories, too? Besides, this isn't on the front page, and obviously only a few people are reading it, anyway. Cut 'em some slack.
Where are my mod points when I need them... seriously. I am sick of hearing people say that RDBMSs are crap or whatever because they can't deal with the fact that DOING HARD STUFF IS HARD.
In the development of a transactional processing system, once the volume of data becomes large and the needs for data integrity and manageability becomes overwhelming... you had soooo better be using a relational database. Object databases just aren't suited for the kind of work that is really important to the majority of applications (unless, at least, the object database is really just an access layer on top of a relational database).
...or maybe I was being sarcastic. Well... sarcastically significant...
What's the null hypothsesis?
Well, alright, I messed up saying Apache. Sorry. The point remains though... if there were GPL'd code inside my banks ATM, would they have to give me the source? The question is: if someone is accessing a GPL'd aplication that is being operated by another party, would the GNU folks' lawyers try to force the operators to give make their source code available? I wouldn't think so, myself, but the legalese can be kind of fuzzy. There are certainly many companies out there who are running GPL-based servers of some sort without any expectation of haing to open up their source.
OK, but there's a slippery slope here. I'm actually kind of familiar with salesforce.com (although not favorably), and they don't really lease the software, they lease the use of their service. So, if you have made software based on Apache, let's say, and you charge people to access your servers... are you "distributing" Apache? Must you provide the source to your servers?
Well, ok... here is what I do/what my home network looks like... admittedly its very similar to what you describe:
cable modem
|
|
linux router ---- wireless LAN
|
|
wired LAN
(that is a linux router sitting between three different networks (three NICs in the router))
On the WAP I'm running max WEP encryption (128 bits). I don't bother to do MAC filtering because MAC could be spoofed *far* more easily than cracking the WEP key. I know that WEP is not a great security protocol, but it is not completely ineffective, either. At the very least, it will slow down an attacker. (Also, there's the fact that there are at least 3 wide-open WLANs in the imediate vicinity: "If you and a friend are being chased by a bear... you don't have to be faster than the bear, just faster than your friend".)
The linux router runs dhcp for both the wired and wireless LANs. It runs FreeS/WAN (free linux IPSec gateway). I use iptables to perform NAT (I only have one real IP address, so the two internal subnets use imaginary IPs) to the cable modem.
I also use iptables on the linux router to enforce simple firewall rules. Inbound new (and not "related") connections from the cable modem are blocked except to allowed services (http and ssh). Apart from dhcp, only ipsec traffic is forwarded from the wireless LAN.
From my laptop (about the only user of the wireless LAN), I use win2k's ipsec (stupid pain in the ass to configure).
And that's about it.
Never tasted paint chips, no.
Yes, FM radio is on tall towers, but not tall enough to clear the horizon. FM radio does "bend" (diffract, really) around the horizon. The reason to put it on tall towers is that it does not have an infinite capacity to bend around the horizon. So by putting it on a tall tower, you can still go further than without. Seriously... get out a pair of binoculars. Do you see the radio tower? No, you don't.
Certainly this has too high of a frequency to gain a whole lot of benefit from difraction around the horizon, but it's not zero, either. Also, you'll note that 802.16, at least currently, can operate in a lot of different ranges of the RF spectrum, so I'm not even going to go through the bother of trying to figure out how much or how little it can bend. The definitive answer is: not a whole lot, but ot zero. Period.
FYI: not going from the marketing blurb. Going from the 802.16 specification that got posted here several weeks ago. Oh, that and a couple physics degrees (though I've been out of the field for a while). Not trying to sound high and mighty; the typical amateur radio enthusiast would know a lot more about the specifics than me. Still, it takes a real man to make a few random insults and unsupported FUD claims as AC. Good for you.
Dude, I was programming computers when I was six. This was the first program I really remember being proud of (circa age six):
10 PRINT "CRASH"
20 GOTO 10
And people question why there should be an Apple in the back of a first grade classroom.
What a shocking number of people seem to be missing is that these are for different purposes! It's like asking why the roads have both cars and trucks on them.
The 802.11's are for wireless LAN. Local area net. They are a replacement for/supplement to ethernet. The various sub-standards do differ, that's true... but they are to serve different purposes (different levels of trade-off in price/range/throughput), and as far as interoprablity goes, that is supposed to be one of the purposes of 802.11g.
802.16 is for wireless MAN. Metropolitan Area Network. That is actually somewhat of a new concept. It is something like a replacement for cable modem/DSL or for T1's, but it's not really the same as either. It is supposed to be a cheaper form of high throughput last-mile delivery.
Despite many very cool attempts made over the past year or two, 802.11 is not particularly suited to delivering the last mile. It's fundamentally only good for a small number of computers over a short distance. That's a fact about the construction of the media access control layer and the radio spectrum. However, it does make for a much cheaper and easily configurable network. You wouldn't want to waste the money on more expensive radio equipment and spectrum in order to carry signals over a mere hundred feet to a handful of computers if you can do it cheaply and easily without.
Anyway, I think that 802.16 is just tremendously cool. Cable modems are neat and all, but anything to increase the competition in the last-mile space is great. Another thing that I would really like to see come about is a grassroots mesh network of 802.11. Just simple folk who share their cable modems with one another. You can route to mine if I can route to yours. That sort of thing. Anyway... getting off topic.
No, no, no. They explicitly said that this does *not* require line of site. Electromagnetic wave propogation is not all like visible light (line of site). Depending on the wavelengths involved, electromagnetic radiation can "bend" significantly. Think about it: do you have a line of site with the antenna tower of your favorite FM radio station? No. What about AM radio? Hell, the low frequencies used in AM can carry hundreds of miles without even factoring in the effect of reflection off the ionosphere.
Anyway, the point is that this is not something that requires an antenna to "hold the beam up" above the horizon.
It's really very sad and disturbing. Fox honestly seems to develop some of the best and most original shows that hit TV these days, along with some of the absolute worst crap. Why do they nearly always choose the crap over the good stuff?
Firefly is a great example. Do I have to mention Futurama? What about Andy Richter being taken off the air for this godawful crap "The Pits"?
*Sigh*.
Well, I'm not saying "engineering bad" or any such nonsense. I just mean to say that what people generally refer to as "software engineering", in practice, is about making programming into an assembly line. It arrises from one fundamental difference between software production and any other kind of industry... and that is that there is nothing really separating the prototype from the product.
You see business people (classicaly) thought of their engineers as the people designing the product and their manufacturers as the people producing the product. They could, grudgingly, separate the two notions. However, in software, the design *is* the product, like in architecture, for example. However, big business thought processes are very invested in the notion of the assembly line. Thus, they start to see their programmers as the assembly line instead of the engineers (in the clasic sense of the product designers).
Anyway, that's the notion I was delving into. There is certainly real engineering involved in creating software, but the business term "software engineering" carries some heavy connotations of turning programmers into cogs.
Contrary to what the author of this review is saying, I really do think that software engineering is different from software craftsmanship. Although you can take many of the things said about software engineering and come up with an application of them similar to an application you could come up with for software craftsmanship, but in practice you wouldn't. This is because the underlying philosophies are very different, and they exist for different purposes. The philosophies/purposes break down like this:
Software Engineering: make the development of software a controllable business process.
Software Craftsmanship: make the best software.
The basic notion of software engineering is to create a *process* which is so perfect that no personal weaknesses in your programmers can hurt the company. A subtle side effect of this is that it also tends to prevent any extremely great individual contribution from having a large impact. That is, the goal is to make all of your coders cogs in a machine. The business owners and managers would much rather have this setup because it makes it easier for them to sleep at night.
Well, the biggest difference has got to be that the two are built for completely different purposes.
BIND is a general purpose name server for use anywhere in the hierarchical dns scheme. That is, in simplest terms, it accepts requests from below, and either serves them or passes the query up (hierarchy = tree).
NSD, according to what is being said is for *authoritative servers only*. That is, it only serves requests, it never passes them up (because it only runs at the nood nodes). It may be true that they intend to make it a general purpose name daemon in the future, but at least for right now, it just simply does not do all of the different things that bind does. One might guess that, because it does fewer things, it does them better, but I sure as hell don't know that to be the case.
I don't expect linux to be less ugly about it on 32bit architecture. I was talking about the upcoming 64 bit architecture.
The current hardware doesn't really allow for >32bit addressing in a graceful way. The article is partly about the growing support for future (near future) 64bit x86 architecture, and I was saying that I liked it. I was citing the possibility of (hopefully) having better memory addressing as part of why, I'm looking forward to it. Last, I was just saying that I can't wait for linux to support this new capability. See the other thread, and Rellik apparently has some stories about the work that has already been done on linux under the (not yet released) 64bit x86 arch.
Neat stuff.
That's exactly what I was saying.
:-P
1. They don't do it yet (how could they? the hardware isn't really out there yet)
2. I think there's a good chance that they will do it soon. Your example only goes along with that.
I'm sorry, but I can't accept the argument that "linux already does 64 bit memory addressing on other architectures, so that means that they already do it on x86 architecture". That doesn't exactly make sense. There are separate bits of code there, so it's not automaticaly done yet. It does mean that, again, hopefully it shouldn't take long.
There are a couple of issues:
1. I'm not going to put it on my servers until it's actually been released and tested. Mostly because my bosses wouldn't let me put it out until it had been (for example) Oracle certified.
2. Even if they have done some demos on pre-release hardware, that's not the same thing as having it done and released
Anyway, I think you must have misunderstood me. Either that or I misunderstood you, or you're just trying to make an argument out an apparent agreement so that we get mod'ed as interesting
Ah. Must have misunderstood you, then. Thought you were saying that you couldn't see linux on Intel / AMD as possibly dominating the server market. And I didn't mean to say that they necessarily would, either... just that it seems an interesting possibility.
Pardon me... You are correct. What I should have said was:
Good support for more than 4 gigs of ram on x86 architecture. Also note that I said "good" support, not just some crappy hack. I'm pretty sure that hasn't yet come to pass... but I'd be happy to be wrong, I guess.
Don't get me wrong, I don't think this is gonna take terribly long (and I sure hope it doesn't).
I don't know that it is so unreasonable to imagine the future of servers based on Intel and AMD running linux. Just look at how much ground theyve covered recently. What is silly is the notion that that doesn't leave room for folks like IBM, and maybe Sun. After all, there is a lot more to a server than just a processor and a free O/S kernel. Personally, I'm kind of taken with the way that (big bad) IBM has been pushing x86 and linux on the small to medium (and growing) end server.
True, linux on x86 is not big iron... yet... but do you relly mean to discount the possibility that it could become a cheaper solution to big iron? For one example, look at Oracle RAC on x86 blades. It's not exactly one megalythic server... it's really more like a beowulf cluster, actually... but what works works.
Anyway... it'll be intersting to see how this all plays out.