I can just see the next generation of Denial of Service attacks on the big webmail houses. The new IIS worms will start "joining up" to hotmail, msn, yahoo, etc. Then, they'll wander around any place where they can just so happen to "drop" the email address for the sniffing spambots!
Am I correct in my impression that Precision Insight included some of the more famous names from SGI and that some of these same people would be part of Tungsten Graphics?
Mystery boxes that do mystery thing to packets and nobody looks inside, Linux is perfect..
You've hit the nail on the head.
The only way to really make money with Linux is to leverage the fact that it is an excellent collection of tools, that creative competent people can put together those tools in ways to make a convenient application/package/box to make people's lives easier. You can sell that and put the money in the bank.
In case no one's noticed, one of the single biggest selling points these days is ease of use, reducing the amount of time I have to invest in dealing with complexities. Saving time and saving the hassle of climbing learning curves is key. Only the small nerd/hobbyist market is interested in the fact that a Linux distro has gcc version 3.0.2. Everyone else could not care less.
With the fantastic reduction in the cost of hardware over the past years and the fact that Windows is now the most expensive essential part of a new PC, Linux can make great inroads into special purpose boxes. Windows remains a bloated complicated mess designed to lock-in market share for the PC office user. It's designed to be hard to interact with unless you are MS - and even they have trouble.
Think here of a brick with 3 or 4 plugs: 110 VAC, RJ-11, RJ-46, USB that plugs into whatever you have to make your life easier.
No one will care if you have a sophisticated and complicated 10000 line Perl script running off Apache and a custom tuned Linux distribution. All they care about is that you've made their life easier and more convenient. Like a TiVo.
The bottom line is that selling to nerds is like selling cars to auto mechanics who have their own parts casting shop. It's a small and difficult market, full of harumphing know-it-alls that want to take things apart piece by piece and examine each component to see if its up to their impossibly high standards. But the really big market for cars is people who want to turn the key and have it work every time without complaint.
General purpose Windows boxes are not the market you want for Linux. Linux will flourish in the next few years, especially the embedded market, with special purpose boxes. Appliances that are so simple to use that it will hurt your nerdly sensibilities.
I find it fascinating that DRAM can be had for $100 per GB these days. I remember buying 1 MB SIMMs for $100 apiece 10 years ago.
The really interesting part is that magnetic drive storage capabilities have risen and the costs decreased over the past 10 years, too.
Otherwise, if we had 1990 vintage hard drives and costs, the DRAM would look real tempting to use as an artificial "hard drive", albeit with doodads to keep it powered up full-time.
So, 10 years from now, when 1 TB DRAM sells for $100, will disk drive technology have kept pace?
On a decidedly on-topic note, though, imaging all 9,629,091 sq km (according to the CIA World Factbook 2001 [cia.gov]) of the USA at 61-cm resolution in 24-bit color would result in 77.6 terabytes of data. That's for one frame; at a rate 1 frame per second, that would be 6.7 exabytes per day. Ask the Almighty to provide you with a 10,000-to-one compression algorithm, and you could get a day's worth of data down under a petabyte.
Not a problem!
Most of the interior of the North American land mass, that which is commonly called the "midwest", can satisfactorily be compressed at ratios of 100,000 to 1 with absolutely zero loss of significant data!
Uniformity in the midwest compensates for coastal areas, where, um, "variability", exists that would otherwise inhibit a high, no-loss compression ratio.
Microsoft has all the trappings of technical support. Call this 1-800-number. We have operators standing by. We employ more programmers than any other PC software house. We advertise that we have support.
But the reality, when you really have a problem, is a less glitzy than the hype. Wait on hold unless you pay extra, be told to reboot, be told to reinstall the OS and apps in a new magic sequence, that it's a hardware maker that has the bad software driver, that the fix will be in the next Service Pack, etc.
Linux OTOH has very sketchy official sounding support. Sure, 1-800 numbers for some paid-for distros, but if you ask Linux users, the vast majority get help out of the bazaar.
And the surprising reality is just how successful such a support model can be. Someone in Germany with the same video card posted his XFree86 config file to Usenet. Go figure!
It's a strange difference. On one hand, being told that you have a designated and well-described support channel that practically turns out to be unsatisfying in many regards, and on the other hand, being told to stake your critical need for help and assistance on a to-be-determined random unidentified stranger in an amorphous mass of users that practically turns out to be more satisfying than you ever expected.
I suppose the Quake 3 numbers are some indication of OpenGL performance for these mass karket cards, but I was curious how these stacked up against the traditional high end OpenGL cards (Oxygen, FireGL, etc. or even a whole SGI system) so that a price/performance comparison could be made. If CPU's are any indication, the market size for these cards could drive their performance to almost acceptable levels in more professional OpenGL applications and certainly at a lot less cost.
are part of a music industry-wide attempt to stop online music piracy.
Gotta hand it to them for defining the language in their own terms - that wins half the battle in the sea of unwashed masses. Kind of like defining your opponents as "terrorists" and your collaborators as "freedom fighters".
Imagine how this would go over if the language were altered to read:
are part of a music industry-wide attempt to stop unrestricted online distribution of music.
This doublespeak is continued with phrases like "Digital Rights Management" that IMHO is more accurately depicated as "Content Use Restriction". Suffice it to say, you'll never see the daily newspapers and national media outlets use any terms except those generated by their owners.
This is all to be expected, though, as evidenced by how he term "hacker" has acquired a strange foreboding and malevolence in the popular media, whereas the technically adept, those most like to "hack", know the difference between a hacker and a cracker.
Younger readers may not be familiar with a similar earlier threat to the American Way of Life.
Fluoridated water was widely suspected to a communist plot , mostly to induce widespread sterility.
Fortunately, alert citizens foiled the effort by placing their water in quart-sized glass jars on top of American flags in direct sunlight for several hours prior to drinking. As a consequence, the intended effect of sterility was mitigated and the only after effects of the threat have been the subnormal intelligence of offspring.
A single Linux box with sendmail and imap would seem to be a lot more capable.
My workplace generally uses MS Exchange and they do indeed require more servers and tinier inboxes than I am accustomed to in a Unix environment. Probably the license fees are higher, too.
But, to be fair, I think the reason those Exchange servers only handle a fraction of the workload is that they are really being asked to do a lot more work behind the scenes: running SQL, running LDAP, managing calendars, deleting vbs attachments and replacing them with text messages before the Lookout clients get hold of them, providing GUIs to the admins, etc. I have to think a Unix server doing all those things would be burdened, too.
The users are generally quite happy using Exchange, except for the viri and for the limitations on their mailbox sizes and occasional mysteries about old backed-up email disappearing.
Interestingly, though, we have UNIX based sendmail servers ahead of the Exchange servers, which makes for a nice fast means of checking inbound mail. It costs nothing and gives a layer of protection and flexibility.
On my end as a user, I'll use fetchmail when my inbox is migrated from local and NFS mountable mbox files to whatever the format is on the Exchange server.
Exchange reliability has been pretty good since a few teething problems a month or two after it was installed. It's not quite where it should be: the Goner worm caused the Exchange admins to shutdown service for a few hours, which inconvenienced more than a few users. Otherwise, it's been humming for a couple of years.
Exchange is a good product. I would really hate to see it used as lever for lockin, but I fear it might.
FWIW, Domino was a very close contender in our evaluation process. I have no idea what its capabilities are these days, but you should probably take a look at it, too.
Hmmmm...[So I know next to nothing about how the kernel does its work.]
With that qualification made in advance, I'll ask this question:
Why can't the
different process schedulers that might be appropriate to different work mixes, if they are significantly different algorithms, be loadable kernel modules?
Is it that the code necessarily bleeds into too many routines? Is VM management similarly impractical to shove into a loadable kernel module?
But you neglect to emphasize just how critically important this will be to an effective remedy.
Consider a "Use Case" - I'm using an advanced internet/computer/software term here - to illustrate the effectiveness of this part of the remedy.
Aggrieved small software supplier: "Hey! MS told me they would work with me so my exciting new application could be brought out in Windows SX, but they changed the API and released a competitive product that, while technically inferior to mine, will swallow the marketplace whole due to preinstalled base on new Windows SX computers!"
DOJ:"API? What? Microsoft changing their Private Investigator? I didn't think they had one! At least, not the last few months that we've been working closely with them to help restore innovation in America."
Yeah, a more condemming story title, as far as Sun is concerned, would be to accuse them of being as sloppy and arrogant as MS.
OTOH, if the markets and positions of Sun and MS were reversed I would expect Bill Gates and Scott McNealy to be able to instantaneously play the reverse roles without so ever as missing a single beat.
make sure the publisher's public key is really the publisher's
Aye, there's the rub!
It really takes an independent confirmation route to verify the veracity of some random downloaded package.
It galls me to no end seeing a download site providing "one-stop" authentication: here's the package, here's the signature, here's the key!
Proving identity and authenticity in this kind of environment would be improved if there were multiple authorities for one to use. Anything else subjects you to the risk of living in Dr Morarty's HollowDeck, if you remember that particular episode of Star Trek TNG.
The network downloaded packages have to
be verified independently, using
public keys burned on the CD distro you bought for cash, on impulse, in a random location,
additional public keys on floppies that you wrote from an entirely different computer and network connection,
phone calls verifying fingerprints of keys
many, many open certifying authorties that are not run by governments or corporations with vested interests that would be harder to compromise en masse,
users that are less inclined to sacrifice security for convenience
Nothing is perfect, but you can tighten things down to the point where your spoofability risk is less.
So, although I'm a great fan of AMD's price performance ratio for the Athlon, I get from the review that there is precious little perceptible difference in performance for the three highest speed grades of Athlon.
And that memory starvation is occuring.
While RAMBUS has galled everyone by their legal tactics, I think there is a fundamental need for more memory BW for the higher clocked Athlons.
The P4, while over-hyped in the consumer marketplace for MHz, does show that memory speed helps for some apps once the memory transfer gets established.
The Athlon's great integer performance and the apparent lower latency of DDR are nice, but
they don't seem to be enough at these speeds.
I *really* fail to see why it's a reduction in freedom. What can you not do in front of a camera, that you couldn't do before? Apart from commit a crime and get away with it? If you really object to being filmed, then don't live in the city. I live in Cambridge (UK) and I'm probably filmed several times a day. Does it bother me? Not in the least. Why should it?
You're right, it shouldn't bother you, as long as you're comfortable with larger parts of your life being on public display as technology improves.
Arguments to the contrary typically rely on a premise along the lines of the definition of "crime" not being to your liking. If your government defines crime in a manner to your liking, and always will in future, then there is no problem whatsoever.
On the other hand, if your definitions of crime do not coincide with those of the government, (say PRC, Saudi Arabia, Indonesia, North Korea, other places at different times), then you might be bothered by those cameras. Slander of the state may be a serious crime.
Those governments, too, would justify their policies based on the same statements you just gave.
This is all fine and good - using Linux for servers is a great business decision. No licensing hassles, stays up like a champ and keeps on performing. End of story. Let's move on.
But what about:
Doing system administration for large LANs of Linux desktops?
Over the years we've been running RISC workstations that are becoming increasingly expensive from a hardware standpoint relative to what can be got in the x86 world.
We'd like to take advantage of the price performance advantage in hardware as well as the increasing maturity of Linux desktop end user applications (which are getting real close now). It seems like a lot more applications are available for Linux desktop than many of the traditional commercial Unices.
The problem is that everyone I know that runs Linux runs their workstation or laptop as their own cowboy system administrator. They typically don't worry about integrating dozens or hundreds of these things together in such a way that a small support staff can manage them effectively.
You know the kinds of systems.
Haphazard applications installed whereever they felt like
distro installed out of the box without enough applications
no patches applied for necessary security updates
strange hardware hanging off moldy interfaces,
never thinking about whether it might be nice to use something like NIS (but I know that's not good enough) or automount,
never providing regular user file backup,
deciding whether to put apps on a central server or each desktop, (pros and cons either way)
how to handle upgrades,
etc.
So what I want to know is:
Has anyone done this?
How did it work? What should we look out for? What is the advantages and disadvantages? Good tools? Web sites?
We have a monstrously large software project with home grown kludges for building on multiple platforms that is a mess of shell scripts and makesfiles. It's ugly and the time required to keep fixing and extending this system is a heavy burden. Plus, it's only tolerable to use.
I've used autoconf a little on a different smaller project and I know this much about it.
When autoconf works, it works great. As a user, there's great delight in typing those 3 magic commands and having a whole series of feature tests fire off and configure the build process. And, as a developer, every time the system works (and it works more than kludge systems), it saves me from hassles of porting to platform de jour. If you look at some fairly complicated systems such as Octave or teTeX build, it's nothing short of amazing.
However, that said, autoconf is complicated. And, you really have no choice but to learn a fair amount of the complications to deal with the issues that will inevitably come up during cross platform testing. I've mostly learned autoconf, a little of automake and almost none of libtool. The m4 macro language for defining the autoconf macros has syntax that always gives me nausea.
If you implement autoconf for your project, great. But, expect a substantial fraction of your time-savings from it to be dedicated to becoming more of an expert at autoconf, m4, sh, etc.
autoconf is better than imake, IMHO, but it sure is short of being as good as it should be. Large projects can justify the time for a person learning the intracacies of autoconf; small projects cannot, unless you happen to know it already. Learning autoconf is kind of like learning nroff just to write a man page - the time investment is more justifiable if you use your expertise to write more than one of them, or to write a really important man page.
P.S. Is there any chance that the software carpentry project will come out with something soon? Some of their early submissions for improved build tools really sounded intriguing, like Tan, an XML based description.
Umm... since when is Debian not open, free and distributed?
Sorry. Quite right - since never has Debian been closed.
I didn't mean to imply they were closed.
I only included them in an incomplete list of known distributors of Linux and GNU that might do some testing as part of their release process.
My main point, obscured by my poor capacity for expressing coherent ideas, was to advocate the establishment of a formal open database that provides functional, benchmark and performance information about different flavors of the kernel in combination with different flavors of hardware.
Along the same lines, a deliberately heterogeneous Beowulf cluster might be useful for testing kernel versions to see the impact of proposed patches and changes.
Too often I hear kernel developers lapse into arguments about VM schemes, etc. where the arguments cannot be resolved because they depend upon actual empirical data that the developers do not yet have!
Yes, there might be benefits for a new scheme under some circumstances and drawbacks for the same scheme under other circumstances. But we won't know until testing on various hardware with typical application suite combinations if the ratio of advantageous/disadvantageous is 95/5 or 5/95.
<operativeword>Imagine</operativeword> data something along the lines of:
A 386 with 12 MB with two ISA Ethernet cards had its NAT performance improve by 10% from 2.4.3 to 2.4.4
A dual PIII running Apache with KDE user apps starting and stopping had 15% decreased throughput after 2 hours of uptime after applying the foobar VM patch to 2.4.8
What's the best way to tell which kernel is best? Run it for about 2 months on a wide variety of hardware, with a wide variety of software loads. Record incidents and map those against known problems, apply available patches for those that will impact you the most. Re-test.
Sound advice, and I'm certainly glad to know that the big distributors of Linux do testing like this.
In the long haul, however, I'd feel more comfortable if there were something open, free and distributed that accomplished the same thing. Just in case any of those good testers at RH, SuSE, Mandrake, Caldera, Debian... move on from testing things on really weird old hardware combinations, like the kinds you might find in schools or in the third world, for example.
Something like a database with motherboard, chipset, CPU, peripherals, kernel version alongside uptime and perhaps some rudimentary performance figures. Each user could contribute an entry to the database so that a very rapid feedback mechanism would be available to kernel hackers due to the size of the user base reporting in a methodical way.
A more organized system would sure beat the anecdotal empirical approach of
"Try this patch. - Works for me. - Wait, doesn't work for me!"
Slashdot Mirror
I can just see the next generation of Denial of Service attacks on the big webmail houses. The new IIS worms will start "joining up" to hotmail, msn, yahoo, etc. Then, they'll wander around any place where they can just so happen to "drop" the email address for the sniffing spambots!
Yessir.
I've often said the same:
Am I correct in my impression that Precision Insight included some of the more famous names from SGI and that some of these same people would be part of Tungsten Graphics?
You've hit the nail on the head.
The only way to really make money with Linux is to leverage the fact that it is an excellent collection of tools, that creative competent people can put together those tools in ways to make a convenient application/package/box to make people's lives easier. You can sell that and put the money in the bank.
In case no one's noticed, one of the single biggest selling points these days is ease of use, reducing the amount of time I have to invest in dealing with complexities. Saving time and saving the hassle of climbing learning curves is key. Only the small nerd/hobbyist market is interested in the fact that a Linux distro has gcc version 3.0.2. Everyone else could not care less.
With the fantastic reduction in the cost of hardware over the past years and the fact that Windows is now the most expensive essential part of a new PC, Linux can make great inroads into special purpose boxes. Windows remains a bloated complicated mess designed to lock-in market share for the PC office user. It's designed to be hard to interact with unless you are MS - and even they have trouble.
Think here of a brick with 3 or 4 plugs: 110 VAC, RJ-11, RJ-46, USB that plugs into whatever you have to make your life easier.
No one will care if you have a sophisticated and complicated 10000 line Perl script running off Apache and a custom tuned Linux distribution. All they care about is that you've made their life easier and more convenient. Like a TiVo.
The bottom line is that selling to nerds is like selling cars to auto mechanics who have their own parts casting shop. It's a small and difficult market, full of harumphing know-it-alls that want to take things apart piece by piece and examine each component to see if its up to their impossibly high standards. But the really big market for cars is people who want to turn the key and have it work every time without complaint.
General purpose Windows boxes are not the market you want for Linux. Linux will flourish in the next few years, especially the embedded market, with special purpose boxes. Appliances that are so simple to use that it will hurt your nerdly sensibilities.
I find it fascinating that DRAM can be had for $100 per GB these days. I remember buying 1 MB SIMMs for $100 apiece 10 years ago.
The really interesting part is that magnetic drive storage capabilities have risen and the costs decreased over the past 10 years, too.
Otherwise, if we had 1990 vintage hard drives and costs, the DRAM would look real tempting to use as an artificial "hard drive", albeit with doodads to keep it powered up full-time.
So, 10 years from now, when 1 TB DRAM sells for $100, will disk drive technology have kept pace?
Not a problem!
Most of the interior of the North American land mass, that which is commonly called the "midwest", can satisfactorily be compressed at ratios of 100,000 to 1 with absolutely zero loss of significant data!
Uniformity in the midwest compensates for coastal areas, where, um, "variability", exists that would otherwise inhibit a high, no-loss compression ratio.
Microsoft has all the trappings of technical support. Call this 1-800-number. We have operators standing by. We employ more programmers than any other PC software house. We advertise that we have support.
But the reality, when you really have a problem, is a less glitzy than the hype. Wait on hold unless you pay extra, be told to reboot, be told to reinstall the OS and apps in a new magic sequence, that it's a hardware maker that has the bad software driver, that the fix will be in the next Service Pack, etc.
Linux OTOH has very sketchy official sounding support. Sure, 1-800 numbers for some paid-for distros, but if you ask Linux users, the vast majority get help out of the bazaar.
And the surprising reality is just how successful such a support model can be. Someone in Germany with the same video card posted his XFree86 config file to Usenet. Go figure!
It's a strange difference. On one hand, being told that you have a designated and well-described support channel that practically turns out to be unsatisfying in many regards, and on the other hand, being told to stake your critical need for help and assistance on a to-be-determined random unidentified stranger in an amorphous mass of users that practically turns out to be more satisfying than you ever expected.
No wonder many people are confused.
I suppose the Quake 3 numbers are some indication of OpenGL performance for these mass karket cards, but I was curious how these stacked up against the traditional high end OpenGL cards (Oxygen, FireGL, etc. or even a whole SGI system) so that a price/performance comparison could be made. If CPU's are any indication, the market size for these cards could drive their performance to almost acceptable levels in more professional OpenGL applications and certainly at a lot less cost.
Any references?
are part of a music industry-wide attempt to stop online music piracy.
Gotta hand it to them for defining the language in their own terms - that wins half the battle in the sea of unwashed masses. Kind of like defining your opponents as "terrorists" and your collaborators as "freedom fighters".
Imagine how this would go over if the language were altered to read:
This doublespeak is continued with phrases like "Digital Rights Management" that IMHO is more accurately depicated as "Content Use Restriction". Suffice it to say, you'll never see the daily newspapers and national media outlets use any terms except those generated by their owners.
This is all to be expected, though, as evidenced by how he term "hacker" has acquired a strange foreboding and malevolence in the popular media, whereas the technically adept, those most like to "hack", know the difference between a hacker and a cracker.
Younger readers may not be familiar with a similar earlier threat to the American Way of Life.
Fluoridated water was widely suspected to a communist plot , mostly to induce widespread sterility.
Fortunately, alert citizens foiled the effort by placing their water in quart-sized glass jars on top of American flags in direct sunlight for several hours prior to drinking. As a consequence, the intended effect of sterility was mitigated and the only after effects of the threat have been the subnormal intelligence of offspring.
At least, that's what I heard from my father.
Wow, that's like, 116 mailboxes per server. Yeah, scales really well.
Well, yes, you're right.
A single Linux box with sendmail and imap would seem to be a lot more capable.
My workplace generally uses MS Exchange and they do indeed require more servers and tinier inboxes than I am accustomed to in a Unix environment. Probably the license fees are higher, too.
But, to be fair, I think the reason those Exchange servers only handle a fraction of the workload is that they are really being asked to do a lot more work behind the scenes: running SQL, running LDAP, managing calendars, deleting vbs attachments and replacing them with text messages before the Lookout clients get hold of them, providing GUIs to the admins, etc. I have to think a Unix server doing all those things would be burdened, too.
The users are generally quite happy using Exchange, except for the viri and for the limitations on their mailbox sizes and occasional mysteries about old backed-up email disappearing.
Interestingly, though, we have UNIX based sendmail servers ahead of the Exchange servers, which makes for a nice fast means of checking inbound mail. It costs nothing and gives a layer of protection and flexibility.
On my end as a user, I'll use fetchmail when my inbox is migrated from local and NFS mountable mbox files to whatever the format is on the Exchange server.
Exchange reliability has been pretty good since a few teething problems a month or two after it was installed. It's not quite where it should be: the Goner worm caused the Exchange admins to shutdown service for a few hours, which inconvenienced more than a few users. Otherwise, it's been humming for a couple of years.
Exchange is a good product. I would really hate to see it used as lever for lockin, but I fear it might.
FWIW, Domino was a very close contender in our evaluation process. I have no idea what its capabilities are these days, but you should probably take a look at it, too.
Hmmmm...[So I know next to nothing about how the kernel does its work.]
With that qualification made in advance, I'll ask this question:
Is it that the code necessarily bleeds into too many routines? Is VM management similarly impractical to shove into a loadable kernel module?Apologies in advance if the question is too dumb.
They can only snitch to the DOJ.
But you neglect to emphasize just how critically important this will be to an effective remedy.
Consider a "Use Case" - I'm using an advanced internet/computer/software term here - to illustrate the effectiveness of this part of the remedy.
Aggrieved small software supplier: "Hey! MS told me they would work with me so my exciting new application could be brought out in Windows SX, but they changed the API and released a competitive product that, while technically inferior to mine, will swallow the marketplace whole due to preinstalled base on new Windows SX computers!"
DOJ:"API? What? Microsoft changing their Private Investigator? I didn't think they had one! At least, not the last few months that we've been working closely with them to help restore innovation in America."
"Excuse me, are you of Middle Eastern descent?"
Yeah, a more condemming story title, as far as Sun is concerned, would be to accuse them of being as sloppy and arrogant as MS.
OTOH, if the markets and positions of Sun and MS were reversed I would expect Bill Gates and Scott McNealy to be able to instantaneously play the reverse roles without so ever as missing a single beat.
make sure the publisher's public key is really the publisher's
Aye, there's the rub!
It really takes an independent confirmation route to verify the veracity of some random downloaded package.
It galls me to no end seeing a download site providing "one-stop" authentication: here's the package, here's the signature, here's the key!
Proving identity and authenticity in this kind of environment would be improved if there were multiple authorities for one to use. Anything else subjects you to the risk of living in Dr Morarty's HollowDeck, if you remember that particular episode of Star Trek TNG.
The network downloaded packages have to be verified independently, using
- public keys burned on the CD distro you bought for cash, on impulse, in a random location,
- additional public keys on floppies that you wrote from an entirely different computer and network connection,
- phone calls verifying fingerprints of keys
- many, many open certifying authorties that are not run by governments or corporations with vested interests that would be harder to compromise en masse,
- users that are less inclined to sacrifice security for convenience
Nothing is perfect, but you can tighten things down to the point where your spoofability risk is less.Why not name it more accurately?
Content Use Restriction Operating System
OTOH, "CUR-OS" kinda reminds me of some old GNU README files that referred to MS-DOG. There would probably be too much confusion between the canines.
So, although I'm a great fan of AMD's price performance ratio for the Athlon, I get from the review that there is precious little perceptible difference in performance for the three highest speed grades of Athlon.
And that memory starvation is occuring.
While RAMBUS has galled everyone by their legal tactics, I think there is a fundamental need for more memory BW for the higher clocked Athlons.
The P4, while over-hyped in the consumer marketplace for MHz, does show that memory speed helps for some apps once the memory transfer gets established.
The Athlon's great integer performance and the apparent lower latency of DDR are nice, but they don't seem to be enough at these speeds.
I *really* fail to see why it's a reduction in freedom. What can you not do in front of a camera, that you couldn't do before? Apart from commit a crime and get away with it? If you really object to being filmed, then don't live in the city. I live in Cambridge (UK) and I'm probably filmed several times a day. Does it bother me? Not in the least. Why should it?
You're right, it shouldn't bother you, as long as you're comfortable with larger parts of your life being on public display as technology improves.
Arguments to the contrary typically rely on a premise along the lines of the definition of "crime" not being to your liking. If your government defines crime in a manner to your liking, and always will in future, then there is no problem whatsoever.
On the other hand, if your definitions of crime do not coincide with those of the government, (say PRC, Saudi Arabia, Indonesia, North Korea, other places at different times), then you might be bothered by those cameras. Slander of the state may be a serious crime.
Those governments, too, would justify their policies based on the same statements you just gave.
This is all fine and good - using Linux for servers is a great business decision. No licensing hassles, stays up like a champ and keeps on performing. End of story. Let's move on.
But what about:
Over the years we've been running RISC workstations that are becoming increasingly expensive from a hardware standpoint relative to what can be got in the x86 world.
We'd like to take advantage of the price performance advantage in hardware as well as the increasing maturity of Linux desktop end user applications (which are getting real close now). It seems like a lot more applications are available for Linux desktop than many of the traditional commercial Unices.
The problem is that everyone I know that runs Linux runs their workstation or laptop as their own cowboy system administrator. They typically don't worry about integrating dozens or hundreds of these things together in such a way that a small support staff can manage them effectively.
You know the kinds of systems.
So what I want to know is:
How did it work? What should we look out for? What is the advantages and disadvantages? Good tools? Web sites?So, like, how does this XP embedded fit into an overall strategy that has seen WinCE and even NT embedded?
This seems to be one of those corporate gaffes.
Remember 1994 and Java?
"What a great programming language - I know! - let's tie it in as Web client!"
Along the same lines 2001:
"I know! This .NET is such a great thing we'll shove into those hot new "embedded devices" everyone is talking about!"
<forehead wrinkles>
We have a monstrously large software project with home grown kludges for building on multiple platforms that is a mess of shell scripts and makesfiles. It's ugly and the time required to keep fixing and extending this system is a heavy burden. Plus, it's only tolerable to use.
I've used autoconf a little on a different smaller project and I know this much about it.
When autoconf works, it works great. As a user, there's great delight in typing those 3 magic commands and having a whole series of feature tests fire off and configure the build process. And, as a developer, every time the system works (and it works more than kludge systems), it saves me from hassles of porting to platform de jour. If you look at some fairly complicated systems such as Octave or teTeX build, it's nothing short of amazing.
However, that said, autoconf is complicated. And, you really have no choice but to learn a fair amount of the complications to deal with the issues that will inevitably come up during cross platform testing. I've mostly learned autoconf, a little of automake and almost none of libtool. The m4 macro language for defining the autoconf macros has syntax that always gives me nausea.
If you implement autoconf for your project, great. But, expect a substantial fraction of your time-savings from it to be dedicated to becoming more of an expert at autoconf, m4, sh, etc.
autoconf is better than imake, IMHO, but it sure is short of being as good as it should be. Large projects can justify the time for a person learning the intracacies of autoconf; small projects cannot, unless you happen to know it already. Learning autoconf is kind of like learning nroff just to write a man page - the time investment is more justifiable if you use your expertise to write more than one of them, or to write a really important man page.
P.S. Is there any chance that the software carpentry project will come out with something soon? Some of their early submissions for improved build tools really sounded intriguing, like Tan, an XML based description.
For having the guts to take a stance against this particular settlement.
Apart from Californian resistance, much of the gist of this story has been covered by an earlier one.
Likewise, my opinion has been expressed there, including why it takes a great deal of courage to stand up to this settlement.
Yeah!
I just typed in my credit card number and found 15 hits on web sites involving videos of hot young goats.
Umm... since when is Debian not open, free and distributed?
Sorry. Quite right - since never has Debian been closed.
I didn't mean to imply they were closed.
I only included them in an incomplete list of known distributors of Linux and GNU that might do some testing as part of their release process.
My main point, obscured by my poor capacity for expressing coherent ideas, was to advocate the establishment of a formal open database that provides functional, benchmark and performance information about different flavors of the kernel in combination with different flavors of hardware.
Along the same lines, a deliberately heterogeneous Beowulf cluster might be useful for testing kernel versions to see the impact of proposed patches and changes.
Too often I hear kernel developers lapse into arguments about VM schemes, etc. where the arguments cannot be resolved because they depend upon actual empirical data that the developers do not yet have!
Yes, there might be benefits for a new scheme under some circumstances and drawbacks for the same scheme under other circumstances. But we won't know until testing on various hardware with typical application suite combinations if the ratio of advantageous/disadvantageous is 95/5 or 5/95.
<operativeword>Imagine</operativeword> data something along the lines of:
A 386 with 12 MB with two ISA Ethernet cards had its NAT performance improve by 10% from 2.4.3 to 2.4.4
A dual PIII running Apache with KDE user apps starting and stopping had 15% decreased throughput after 2 hours of uptime after applying the foobar VM patch to 2.4.8
You get the idea.
What's the best way to tell which kernel is best? Run it for about 2 months on a wide variety of hardware, with a wide variety of software loads. Record incidents and map those against known problems, apply available patches for those that will impact you the most. Re-test.
Sound advice, and I'm certainly glad to know that the big distributors of Linux do testing like this.
In the long haul, however, I'd feel more comfortable if there were something open, free and distributed that accomplished the same thing. Just in case any of those good testers at RH, SuSE, Mandrake, Caldera, Debian ... move on from testing things on really weird old hardware combinations, like the kinds you might find in schools or in the third world, for example.
Something like a database with motherboard, chipset, CPU, peripherals, kernel version alongside uptime and perhaps some rudimentary performance figures. Each user could contribute an entry to the database so that a very rapid feedback mechanism would be available to kernel hackers due to the size of the user base reporting in a methodical way.
A more organized system would sure beat the anecdotal empirical approach of