Servers shouldn't be moving on a regular basis, and great care should be taken whether or not they are attached to external devices. Also, what other FW devices would you want to connect directly to a server that wouldn't go as well through a FW hub?
Unless it's disabled in an OEM install script or deployment settings, XP bitches about blank passwords at every step of installation. The only way that a home user would set up a passwordless XP box is if they acquired XP in an unsanctioned way, which results in an install with questionable security for different reasons.
Also note that 'Administrator' is comparable with 'wheel', and that 'System' is comparable with 'root' in terms of access to the low-level system. Becomoing or running code as interactive System is not easily done, with or without a web page.
Many office apps tie the document layout to the specs of the local/default printer, which is annoying when moving between computers attached to printers that have different imagable areas. Margins often change between different lines/classes of printers, or between printers with different default common paper sizes (A4 vs letter vs letter (small)...).
Anyone else think maybe Apple just repackaged the iBook's motherboard and turned up the speed a bit?
No, since the memory form factors are different, as is the port configuration, and there's the obvious problem of fitting a 10"x5" iBook logic board into a space with half that area...
It's apparent we have different expectations from the server hardware and software we buy and use.
I expect my admins to be professionals and to handle sensitive equipment and software correctly and with care!
Hardware wise the apple xserves are the most fragile of all of our server. We bought three and something went wrong with two of them right off the bat. Mostly small piddly things but they are really really fragile.
Ahh yes, 'something' went wrong. I have 'something' in my toolchest that can make any computer go wrong...
If they're 'piddly things', are they important?
Also, computer hardware and software don't usually go wrong on their own accord, that is, without environmental interaction. Were these DOA or PEBKAC problems?... starting last year apple server.... Software wise mac os x server is nowhere near the coherence of either freebsd or windows.
Is your percieved lack of coherence due to the design of the software, or your unfamiliarity with its usage? How much of it is the result of your having to (shocking!) learn new ways to use a new operating system? It's clear from your other posts on this thread that your experience is highly linked to Dell systems. Would it surprise you that Xserves do not behave exactly like Dells?
As for darwinports well it would be nice if all of the ports actually built. So far about 1/3rd of the ones I attempted have failed to build
Again, which ones? Or better yet, explain why you originally criticized darwinports in the context of I/O-bound apps on the Xserve hardware in a cost analysis thread in a story about computer hardware.
And surely, you're not speaking from experience trying to do serious HPC using generic, unoptimized multi-platform source on three nodes...
Their cases are aluminum, while that may be l33t it also means they are fragile as all get out.
Presumably, you speak of Apple's Xserve product, since you don't actually specify what you try to bash here.
The benefits from increased thermal transfer efficiencies and decreased mass far outweigh the cost of having to service the units according to the included instruction manuals and safe electronics handling techniques. Properly installed Xserves in fixed racks aren't generally subject to conditions that would compromise the structural integrity of the case.
Twist a screw too tight and you have stripped the damned thing.
Poor motor control or inappropriate use of power tools will strip threads on any case.
The rail racks are also just poorly designed. Compare them to something made by HP or Dell and see for yourself.
In your professional engineering estimation, how might the Apple product be improved? What exactly would you change?
Go ahead and muck with those postfix or samba conf files but don't come crying to apple when it decides to wipe your configuration and put it's own instead.
If you know how to manually configure a service by editing the config file, you don't need the GUI. If you don't know about making backup copies of config files before editing them, you have no business configuring a server.
Whatever point you attempted to make is moot in professional environments.
You want to learn brand new commands for everything? I thought you did. Virtually none of the commands you have reached for over the years work.
The vast majority of POSIX commands and options work for me. What command set did you learn and why do you assume that everyone else learned the same?
Don't even get me started on darwinports....
Please indulge me and the rest of the community with your insights so that we may improve the software.
Although, feel no pressure to answer until you've been to a server room with working computers in it.
this would be a photojournalists/sports photographer's dream not to have to switch out cards every 50 or 80 pictures
I'd almost prefer to port around the equivilant dollar value in consumer CF cards since my 6 MP dSLR makes _at least_ 48 MB/s of data shooting TIFFs in sny of the burst modes. Firing the files off at 55 Mbps without cache would bottleneck the image buffer and camera in about 2s, or 1s on a >10 MP real dSLR.
Also, if I'm putting a harddrive on my body, I'd use much faster USB2 or FW to transfer files.
I think that the revelation that there is only marketing in play for turning WiFi off, not technical problems as they initially claimed,
Hacked drivers running on hardware for less than a month doesn't mean that there aren't technical problems. No one to this point has examined the EM emissions profile of the unsupported configuration, nor power consumption, nor a whole host of other engineering and QA things that need to be done to make sure nothing is running out of spec, if only to make sure that the device combination works _well_ now and into the future.
The unsupported Treo hammer can fail in both obvious and subtle ways after some inconsistent number of uses outside its design and practical tolerances, just like the unsupported Treo WiFi client might. We won't know if this will result in subtle time-delayed failures until an engineer who knows the Treo hardware examines how everything in this configuration interacts.
It could be the case that both the engineers and marketing delayed the WiFi product feature because of some fatal flaw that the developer commuinity has not yet noticed. It could be that p1 feels the very limited battery life while using WiFi, as the community has discovered, makes this feature impractical for most users. We don't know.
In any case, since we don't know what p1 are thinking, statements about their motives and intents are speculation at best and attributing malace to either does a great disservice to thoughtful discussion.
kidlatj: "For all the Treo 600 members with their fingers crossed, Sorry to break the bad news guys, after several more crashes we have decided to research the different processers and found out that the T600 has the TI OMAP 144MHz processer where all the devices that are included on the driver (also the T650) are built around the Intel XScale (PXA 270). So the code in the palm driver is written in the language specific to a different processer. I'm not saying that it is impossable, just Palm might have to release a new driver that is OMAP specific. I will definatly keep on this, but this is the current problem."
This would be copyright infringement, if anything, since the final product is an unauthorized derivative/compilation of drivers from a bunch of driver sets.
See this thread for more information about WiFi drivers on the 650.
The useful information begins on page 42 and after when he announces that it works, but read everything before it for the story value. (Yes, I read all 1095 posts in the fine thread before posting here...)
If the malware must "tool around with" (I'm assuming you mean carry) executable
I intend the standard meaning, but as applied to the host system instead of cars.
becomes larger and an easier target.
IE/OE worms on the order of 150KB spread with great success, thanks. But file size isn't the point here.
This would make creating vaccines against known infective agents relatively easy.
Great! Now what does that have to do with checksumming existing files?
... not only monitoring the programs resident on the computer, but also messages coming in through the ports. And zip/gzip/bziped files as they are encountered...
Those activities are far beyond the scope of a checksumming tool that lives on the system to verify the integrity of files already there!
... This merely means that there will be a cost to antivirus activity. That's a truth, sorry....
Great! And puppies are cute. Please explain why any of that makes an unprotected manifest of checksums a sufficient antivirus tool.
Secessful [sic] security depends on defense in depth, not on one invulnerable method (because there aren't any).
Indeed. Plain checksumming of executables is neither necessary nor sufficient for modern antivirus tools to be effective, as illustrated by NAV and VirusScan which do not stop changed executables from running, as long as they are not infected with known malware. (This may be different for the non-enterprise versions of the tools, which I don't have access to at the moment.)
Interestingly, some firewalls such as ZoneAlarm do use executable checksums, but to protect _other_ computers by preventing altered files from establishing outbound connections.
Thank you for reiterating the point of my first sentence by example.
It would be trivial for the program to use a unique file name at each installation, so the virus wouldn't know what file to corrupt.
It would be trivial for the malware to make and run a bunch of executable consisting of return(0) to determine, by monitoring the checksumming tool, not only what manifest files/databases the checksum tool uses, but also what checksum calculation is being used (even if we do your random number seed immune system thing). This, however, is not the point.
Unless you can trust the manifest not to change (sign it or keep it elsewhere), if the malware can tool around with executables or system it can also rewrite your manifest. No amount of obscurity in the checksumming mechanism (under whatever licensing regime) fixes that point of weakness.
Regarding the immune system: it protects a different kind of moving target than computer systems in that every cell type that should ever be in the body is already known to the immune system when it goes live. The immune system never needs to deal with new cell types, nor approve of new cell types in the body unlike computers which can have new software installed. Every cell that should be in the body presents a common set of surface peptides and proteins that are similar to a static string checksum (unique to the system on which it runs) compiled into the executable. Cells without that string or with proteins that are foreign usually get picked off. Also, in a body, there is no capacity for the system-wide checksum to change in a body, but in a well-maintained system files must be updated on a repeating basis.
The immune system isn't even that great at preventing infection, as evidenced by the many retroviruses in our genome (rooted!), and look at the spectacular failures that allow HIV and some kinds of cancer to exist in a body for examples of vulnerabilities.
In the end, the analogy is only apt if every file that will ever be in the system of files that require verification has its checksum stored in a non-mutable way before the system goes live. But on such static filesystems, malware are not a threat addressable with file integrity verification anyway.
This bill is not necessarily a right or good advancement since, if enacted, opponents to the spirit of this type of legislation could then point to the existence of this (ineffective) version to abate discussions on any new versions with teeth, with the legislative result of allowing abuse to continue under the guise of protecting citizens.
I would argue that GPL has nothing to do with this type of tool no longer existing for the purpose of stopping malware since it's trivially easy for the malware to defeat such protection without some kind of encryption or signature validation in the checksumming mechanism.
MSAV and related checksum tools simply trap fopen() calls to executable files, hash()ed the executable, and compared the hash() value to the previous hash() value which is stored in an easily writable unprotected database/file before (dis)allowing the fopen(). If malware can easily infect a file, hash() it, and write the value for the infected file to the database without detection, checksumming is useless for determining if the file has been changed. (With MSAV, simply delete chklst.ms before infecting the executable, and the MSAV TSR will make a new chklst.ms file for you.)
The equivalent free program now is md5() which, without [G]PG[P] signing the file storing the hashes, is no more or less useless than MSAV and any other simple checksumming tool at stopping file tampering.
Slashdot Mirror
Servers shouldn't be moving on a regular basis, and great care should be taken whether or not they are attached to external devices. Also, what other FW devices would you want to connect directly to a server that wouldn't go as well through a FW hub?
edit.com wrapped qbasic.exe for DOS 6. /ed <filename>)
(qbasic
DOS 7/Windows 95 and above had a real executable tied to edit, which gained limited LFN support.
Why do they still call x86 PC's "IBM compatible", like in this article?
Because the term has meaning, specifically, "this software runs on the x86 instruction set".
Macs use IBM processors, not Wintel computers!
Why do you call them "Wintel" computers, despite the existance of x86 computers running non-Windows? Because that phrase also has meaning.
IBM no longer even MAKES PC's!
Sure they do
Unless it's disabled in an OEM install script or deployment settings, XP bitches about blank passwords at every step of installation. The only way that a home user would set up a passwordless XP box is if they acquired XP in an unsanctioned way, which results in an install with questionable security for different reasons.
Also note that 'Administrator' is comparable with 'wheel', and that 'System' is comparable with 'root' in terms of access to the low-level system. Becomoing or running code as interactive System is not easily done, with or without a web page.
Now, please FUD off.
I'd love to know where one can make a one-off PCB for $50...
Apples with no such memory
disclaimer
Many office apps tie the document layout to the specs of the local/default printer, which is annoying when moving between computers attached to printers that have different imagable areas. Margins often change between different lines/classes of printers, or between printers with different default common paper sizes (A4 vs letter vs letter (small)...).
It doesn't include a spreadsheet, database, or drawing app
Access for OS X would be nice.
Anyone else think maybe Apple just repackaged the iBook's motherboard and turned up the speed a bit?
No, since the memory form factors are different, as is the port configuration, and there's the obvious problem of fitting a 10"x5" iBook logic board into a space with half that area...
Much like the SPARCplug of yore...
0 0435
http://indigoid.net/gallery.pl/ross-sparcplug/p00
http://www.apple.com/macmini/design.html
It's a single regular 200-pin DDR slot.
It's apparent we have different expectations from the server hardware and software we buy and use.
... starting last year apple server. ... Software wise mac os x server is nowhere near the coherence of either freebsd or windows.
I expect my admins to be professionals and to handle sensitive equipment and software correctly and with care!
Hardware wise the apple xserves are the most fragile of all of our server. We bought three and something went wrong with two of them right off the bat. Mostly small piddly things but they are really really fragile.
Ahh yes, 'something' went wrong. I have 'something' in my toolchest that can make any computer go wrong...
If they're 'piddly things', are they important?
Also, computer hardware and software don't usually go wrong on their own accord, that is, without environmental interaction. Were these DOA or PEBKAC problems?
Is your percieved lack of coherence due to the design of the software, or your unfamiliarity with its usage? How much of it is the result of your having to (shocking!) learn new ways to use a new operating system? It's clear from your other posts on this thread that your experience is highly linked to Dell systems. Would it surprise you that Xserves do not behave exactly like Dells?
As for darwinports well it would be nice if all of the ports actually built. So far about 1/3rd of the ones I attempted have failed to build
Again, which ones? Or better yet, explain why you originally criticized darwinports in the context of I/O-bound apps on the Xserve hardware in a cost analysis thread in a story about computer hardware.
And surely, you're not speaking from experience trying to do serious HPC using generic, unoptimized multi-platform source on three nodes...
Their cases are aluminum, while that may be l33t it also means they are fragile as all get out.
Presumably, you speak of Apple's Xserve product, since you don't actually specify what you try to bash here.
The benefits from increased thermal transfer efficiencies and decreased mass far outweigh the cost of having to service the units according to the included instruction manuals and safe electronics handling techniques. Properly installed Xserves in fixed racks aren't generally subject to conditions that would compromise the structural integrity of the case.
Twist a screw too tight and you have stripped the damned thing.
Poor motor control or inappropriate use of power tools will strip threads on any case.
The rail racks are also just poorly designed. Compare them to something made by HP or Dell and see for yourself.
In your professional engineering estimation, how might the Apple product be improved? What exactly would you change?
Go ahead and muck with those postfix or samba conf files but don't come crying to apple when it decides to wipe your configuration and put it's own instead.
If you know how to manually configure a service by editing the config file, you don't need the GUI. If you don't know about making backup copies of config files before editing them, you have no business configuring a server.
Whatever point you attempted to make is moot in professional environments.
You want to learn brand new commands for everything? I thought you did. Virtually none of the commands you have reached for over the years work.
The vast majority of POSIX commands and options work for me. What command set did you learn and why do you assume that everyone else learned the same?
Don't even get me started on darwinports....
Please indulge me and the rest of the community with your insights so that we may improve the software.
Although, feel no pressure to answer until you've been to a server room with working computers in it.
The WiFi camera isn't subject to data/carrier fees.
Also, think fixed wireless.
this would be a photojournalists/sports photographer's dream not to have to switch out cards every 50 or 80 pictures
I'd almost prefer to port around the equivilant dollar value in consumer CF cards since my 6 MP dSLR makes _at least_ 48 MB/s of data shooting TIFFs in sny of the burst modes. Firing the files off at 55 Mbps without cache would bottleneck the image buffer and camera in about 2s, or 1s on a >10 MP real dSLR.
Also, if I'm putting a harddrive on my body, I'd use much faster USB2 or FW to transfer files.
I think that the revelation that there is only marketing in play for turning WiFi off, not technical problems as they initially claimed,
Hacked drivers running on hardware for less than a month doesn't mean that there aren't technical problems. No one to this point has examined the EM emissions profile of the unsupported configuration, nor power consumption, nor a whole host of other engineering and QA things that need to be done to make sure nothing is running out of spec, if only to make sure that the device combination works _well_ now and into the future.
The unsupported Treo hammer can fail in both obvious and subtle ways after some inconsistent number of uses outside its design and practical tolerances, just like the unsupported Treo WiFi client might. We won't know if this will result in subtle time-delayed failures until an engineer who knows the Treo hardware examines how everything in this configuration interacts.
It could be the case that both the engineers and marketing delayed the WiFi product feature because of some fatal flaw that the developer commuinity has not yet noticed. It could be that p1 feels the very limited battery life while using WiFi, as the community has discovered, makes this feature impractical for most users. We don't know.
In any case, since we don't know what p1 are thinking, statements about their motives and intents are speculation at best and attributing malace to either does a great disservice to thoughtful discussion.
http://discussion.treocentral.com/showthread.php?t =64490&page=46&pp=20
kidlatj: "For all the Treo 600 members with their fingers crossed,
Sorry to break the bad news guys, after several more crashes we have decided to research the different processers and found out that the T600 has the TI OMAP 144MHz processer where all the devices that are included on the driver (also the T650) are built around the Intel XScale (PXA 270). So the code in the palm driver is written in the language specific to a different processer. I'm not saying that it is impossable, just Palm might have to release a new driver that is OMAP specific. I will definatly keep on this, but this is the current problem."
This would be copyright infringement, if anything, since the final product is an unauthorized derivative/compilation of drivers from a bunch of driver sets.
See this thread for more information about WiFi drivers on the 650.
The useful information begins on page 42 and after when he announces that it works, but read everything before it for the story value. (Yes, I read all 1095 posts in the fine thread before posting here...)
One can hammer nails with a Treo 650, but that would not be one of its officially supported uses...
I don't think they've stated that WiFi will never be released. The product is still current; give it time, then start contemplating legal fun.
If the malware must "tool around with" (I'm assuming you mean carry) executable
... not only monitoring the programs resident on the computer, but also messages coming in through the ports. And zip/gzip/bziped files as they are encountered...
... This merely means that there will be a cost to antivirus activity. That's a truth, sorry. ...
I intend the standard meaning, but as applied to the host system instead of cars.
becomes larger and an easier target.
IE/OE worms on the order of 150KB spread with great success, thanks. But file size isn't the point here.
This would make creating vaccines against known infective agents relatively easy.
Great! Now what does that have to do with checksumming existing files?
Those activities are far beyond the scope of a checksumming tool that lives on the system to verify the integrity of files already there!
Great! And puppies are cute. Please explain why any of that makes an unprotected manifest of checksums a sufficient antivirus tool.
Secessful [sic] security depends on defense in depth, not on one invulnerable method (because there aren't any).
Indeed. Plain checksumming of executables is neither necessary nor sufficient for modern antivirus tools to be effective, as illustrated by NAV and VirusScan which do not stop changed executables from running, as long as they are not infected with known malware. (This may be different for the non-enterprise versions of the tools, which I don't have access to at the moment.)
Interestingly, some firewalls such as ZoneAlarm do use executable checksums, but to protect _other_ computers by preventing altered files from establishing outbound connections.
Thank you for reiterating the point of my first sentence by example.
It would be trivial for the program to use a unique file name at each installation, so the virus wouldn't know what file to corrupt.
It would be trivial for the malware to make and run a bunch of executable consisting of return(0) to determine, by monitoring the checksumming tool, not only what manifest files/databases the checksum tool uses, but also what checksum calculation is being used (even if we do your random number seed immune system thing). This, however, is not the point.
Unless you can trust the manifest not to change (sign it or keep it elsewhere), if the malware can tool around with executables or system it can also rewrite your manifest. No amount of obscurity in the checksumming mechanism (under whatever licensing regime) fixes that point of weakness.
Regarding the immune system: it protects a different kind of moving target than computer systems in that every cell type that should ever be in the body is already known to the immune system when it goes live. The immune system never needs to deal with new cell types, nor approve of new cell types in the body unlike computers which can have new software installed. Every cell that should be in the body presents a common set of surface peptides and proteins that are similar to a static string checksum (unique to the system on which it runs) compiled into the executable. Cells without that string or with proteins that are foreign usually get picked off. Also, in a body, there is no capacity for the system-wide checksum to change in a body, but in a well-maintained system files must be updated on a repeating basis.
The immune system isn't even that great at preventing infection, as evidenced by the many retroviruses in our genome (rooted!), and look at the spectacular failures that allow HIV and some kinds of cancer to exist in a body for examples of vulnerabilities.
In the end, the analogy is only apt if every file that will ever be in the system of files that require verification has its checksum stored in a non-mutable way before the system goes live. But on such static filesystems, malware are not a threat addressable with file integrity verification anyway.
This bill is not necessarily a right or good advancement since, if enacted, opponents to the spirit of this type of legislation could then point to the existence of this (ineffective) version to abate discussions on any new versions with teeth, with the legislative result of allowing abuse to continue under the guise of protecting citizens.
I would argue that GPL has nothing to do with this type of tool no longer existing for the purpose of stopping malware since it's trivially easy for the malware to defeat such protection without some kind of encryption or signature validation in the checksumming mechanism.
MSAV and related checksum tools simply trap fopen() calls to executable files, hash()ed the executable, and compared the hash() value to the previous hash() value which is stored in an easily writable unprotected database/file before (dis)allowing the fopen(). If malware can easily infect a file, hash() it, and write the value for the infected file to the database without detection, checksumming is useless for determining if the file has been changed. (With MSAV, simply delete chklst.ms before infecting the executable, and the MSAV TSR will make a new chklst.ms file for you.)
The equivalent free program now is md5() which, without [G]PG[P] signing the file storing the hashes, is no more or less useless than MSAV and any other simple checksumming tool at stopping file tampering.
You mean something like MSAV?
http://www.easydos.com/msav.html