Sun is offering for free (as in beer) the same things that those that are going to pay for support for get with their support contracts. Sure, the free things come without timely feature patches, etc., but the barrier to using Sun software is defintely lowered. For those looking for free (libre) software from Sun, you can mostly get it too. OpenSolaris is an amazing step given the encumberances and continued business model that they had to struggle with. My guess is that most of Sun's customers will continue to pay for support even though they "don't need to." These customers tend to be the ones that believe that a Fortune 500 systems company is better prepared to deal with OS or other software problems than the outsourced IT department of a company that's core business is not software development. Those that get lured in by free beer have the option of switching to full support without changing software bits (unless they went to the libre bits).
With Red Hat, you can get for free (as in beer and freedom) almost the same bits as paying customers get. However, if you decide midstream that you need to switch from a free customer to a paying customer, you also need to change the code that you are running. This switch can be very costly because it disrupts your business.
It seems to me that this is an effort to pressure Red Hat into giving away RHEL. By reducing Red Hat's paying user base, Sun could put them on the ropes a bit. Again, those that feel that they really need support will still pay Red Hat.
Until Red Hat starts giving RHEL away for free, those that are simply going after the lowest (legal) cost of acquisition along with great ISV support and low risk have a clear choice in going with Solaris. This has the potential to at least slow the uptake of RHEL.
Before incorporating significant changes, make sure that the person who wrote the changes has signed copyright papers and that the Free Software Foundation has received and signed them. We may also need a disclaimer from the person's employer.
You are completely wrong on Veritas checkpoints and UFS snapshots. Veritas checkpoints keep a bitmap of the blocks that have changed and does a copy-on-write of only the blocks that change. As such, the following are true
If you remove a 1 gig file, only a couple blocks will change. One block will be the one that stores the directory entry. Another will be the one that contains the appropriate inode table. Any others will be the ones that store the free block bitmap. The odds are that other file system operations have already caused the copy-on-write (COW) for the inode and free block bitmaps. As such, most likely the only change will be to a block of the directory.
If you change 1 byte in a terabyte file, two blocks may change. One will be the block where the byte is stored. The other is the inode for the file so that mtime (modification time) field can be updated.
Adding a file is very similar to the situation found when removing a file.
Depending on the Veritas product used, you may be able to mount your snapshot read-write.
UFS snapshots (introduced in a patch to Solaris 8, standard on Solaris 9) allow you to store the changed blocks on a different backing store (another file system). If you look at the file used on that other file system with ls -l, you will see that it is the same size as the file system. Using du, you will see that it is only the size of the changed data.
On the other hand, you are right when talking about similar things on high-end arrays. For example, on an EMC Symmetrix you can create a Business Continuance Volume (BCV) which is esentially a third mirror that gets synced and split off. On a HP XP, you can create a Business Copy (BC). In this case a RAID5 mirror of your RAID5 data is synced up and split. These are commonly used for backups so that you can mount the disk on your backup server and completely bypass your database server when backing up your 5 terabyte database. Another useful feature of this is for having and instant restore in case an upgrade fails or doing data refreshes to test, staging, and development servers.
As I was reading the announcement, I missed item 42 (Added win2k3 shadow copy operations to VFS interface). Taking a look at the discussion on the samba-technical list, this seems like it is a very cool feature. It paves the way for being able to look at snapshot file systems (Veritas, UFS, LVM, etc.) and even creating a VFS interface that will allow you to browse the last 64 revisions of file a CVS repository. Very cool.
Yeah, there is no place for such programs/protocols, anywhere. And FTP, and HTTP, and SMB, and NFS, and BOOTP/DHCP, and ARP, and DNS, and...
Oh crap. I need some of those protocols that do not provide strong cryptography. Not to mention that in many environments you do not have the flexibility (restricted by PHB) to install "unsupported" software like openssh (on Solaris 8 where it is not part of the OS). Tell me, would the person be better off with SSH installed or not installed if there was not someone around to build the latest version at least three times in the past year? With Solaris 9, Solaris SSH (openssh + patches) is available and there are few excuses for not using it.
I am quite disappointed with HP's recent conduct with two issues related to the DMCA. I am in a senior enough position as a UNIX administrator that I have significant impact in how a multi-million dollar IT budget is spent. HP's invocation of the DMCA reduces my trust in HP as a vendor of secure and reliable technology. Therefore I am less inclined now than I ever have been in the past to purchase HP products.
The first issue is HP's request that Bruce Parens not present his findings on DVD copyright controls. If he is acting on his own behalf, and includes a disclaimer that this is a separate issue from what he does under the employment of HP, he should be allowed to go forth. If he is presenting HP intellectual property, HP has the right and responsibility to protect itself. This, however, does not seem to be the case.
The more disturbing issue is with regards to the handling of SnoSoft's publication of root exploits to the Tru64 operating system. As a UNIX administrator, I am responsible for researching technologies that I will put into production. Many times, these products are used to protect the intellectual property, stability, or other things that are of great importance to my employer's success and my career. If security researchers cannot force many of the bugs out in the open before I evaluate products, I have much more work on my hands. Furthermore, if I find a bug that I know can be used to compromise my system, without the ability to publicly discuss and disclose the bug, I may be unable to get a fix from the vendor or a home-grown workaround. If I am at the complete mercy of my vendors' good will, I fear that I will have a system that lacks stability and security.
Please reconsider your decision to use the Digital Millenium Copyright Act to stifle free speech. Once you come to the realization that the DMCA is not a law that is useful for HP, please put your lobbying efforts into repealing it and push for funding to enforce pre-DMCA laws that already provide more than adequate protections on copyright and other intellectual property issues.
I do not speak for my employer. Please remember, however, that my employer trusts me to make decisions that are in the employer's best interest. Your actions suggest that the purchase of HP products is in the best interest of no employer that I would work for.
This advice is very sound. Be sure, however, that all of your machines have a host-based firewall that makes it so that the only hosts that can communicate with the wireless interface are the DHCP server and the VPN gate and then only over the ports that are required. The VPN tunnel interface can then be treated with relatively the same amount of trust as a hardwired machine inside the firewall.
Without doing this, all of your mobile clients become a very weak link in your network's security: a rogue wiresless node could hack into your laptop running IIS (over the wireless link) then plant a trojan (or just turn on routing) that gives them access to the inside of the firewall through your VPN tunnel.
Microsoft's little fiasco a while back with crackers having access to their source code was essentially this type of attack. Note that in that case it was not a wireless network that was to blame, rather it was a broadband remote user that had a compromised machine.
And they have OEM Licensing.. A couple groups to license it for inclusion in their prodcuts are Ximian ($9.95 per month, or $59.95 purchase) and Suse ($24.95).
A while back I spent some time reading up on LinuxBIOS. A quick look at that page led me to
FreeBIOS (same as LinuxBIOS) and OpenBIOS.
As I recall, poweron to Linux in single user mode was less than 5 seconds. That speed was largely a factor of how fast the code could be read from the EEPROMs.
Please ask Dell, HPQ, IBM, Gateway, and your favorite mother board manufacturers to dump the
crappy old BIOSes and migrate to something modern.
Re:"Next-gen" office from Microsoft, also XML-base
on
StarOffice 6.0
·
· Score: 1
So I have a standard corparate document that was oringally in Word format. I saved it in this nice open OpenOffice 1.0 format, and did a "file" on the document. It told me it was a zip file. Upon unzipping that file, I got the following components:
% file * content.xml: XML document text layout-cache: data META-INF: setgid directory meta.xml: XML document text
ObjBFFFCB51: Microsoft Office Document
settings.xml: XML document text styles.xml: XML document text
So much for cleanly pulling that image out of the document.
This looks like a step in the right direction for Linux acceptance in the professional server market.
This is not what Sun is intending to do. They realize that there are a lot more people out there that are writing code for Linux and making it a desirable OS to use than there are doing the same for Solaris. By making it easier to port from Linux to Solaris, Sun is trying to make it easier for developers to keep Solaris as a top tier platform.
For instance, if you have installed OpenSSH on Solaris, you will have been forced to look into the various methods for getting/dev/urandom or a suitable replacement. After I brought this issue up and reminded Sun that they were trying to get to a Linux-compatible API, they backported their Solaris 9/dev/urandom to Solaris 8 with patch 112438-01. Imagine my shock that Sun actually implemented one of my RFE's.
So long as they don't copy the code they are fine. It is well understood that you can look at GPL code to get ideas for how to implement things, then use the abstracted ideas to write your own implementation. Just don't cut and paste, or end up with code that makes it look like you did.
In my datacenter, the Hitachi array is is every bit as fast as the EMC Symetrix that the Hitachi replaced. The Hitachi array sports 160 GB dual-ported active-active fibre channel drives. They were the first to deliver 160 GB drives in the enterprise market and AFAIK they are the only ones that have dual-ported active-active bus connections.
Microsoft's first witness against antitrust sanctions sought by nine states admitted in court on Tuesday that he asked for a favor when Microsoft Chairman Bill Gates called seeking his testimony.
Jerry Sanders, chief executive of computer chipmaker Advanced Micro Devices, also conceded he had not read the states' proposed sanctions, but that Gates had told him they were "crazy" and would fragment the Windows operating system.
Under some workloads, I can go along with the assertion that a MOSIX cluster is just like having a big machine with a lot of CPU's. It seems to be great for those workloads and I would love to try it out. Those loads tend to be multiple long running (more than a few seconds) and not multithreaded. For MOSIX to be most efficient, there also needs to be fewer jobs than there are CPUs to run them.
Other workloads, however, will not benefit from MOSIX. These statements are based on reading the docs a couple weeks back, not on actual experience.
Under the MOSIX model, when a process forks, the child may run on the current machine or it may migrate somewhere else. If the job is short lived (ls, echo whatever | sed s/blah/baz, you get the point) MOSIX will perform poorly because it will spend more time trying to figure out where the process should run than would have if it had just run the program on the local host.
If you need more CPU time than one CPU can provide and your program is multi-threaded, a single multiprocessor machine will also work better. This is because MOSIX does not yet support threads running on different machines. A 128-node cluster of 386's is going to run Netscape slower than a single 486 because you will only be using one 386 CPU.
For cases where you just have too many jobs for the resources available (CPU or memory), you may be better off with something like Condor. It is great for submitting batch jobs, migrating those jobs around, and only running the number of jobs that the system can handle.
Bruce Perens as sent an open letter to Michael Robertson requesting that they release the code to the software that he wrote that they are distributing.
Alcatel has products in this market too. Take a look at the Alcatel 7340 Home Optical Network Terminal for details. It also has POTS, CATV, DBS, and 10BaseT.
I sure hope that the phone companies do a better job of rolling out FTTU than they have ADSL.
Samba is well known for its ability to act as an NT File/Print server, but it can also act as a primary domain controller. I believe that its PDC capability along with its Unix Password Sync functionality will allow you to accomplish most of what you want. Alternatively Samba also comes with windbindd which allows you to have your Linux and Solaris clients participate in an NT domain.
With Unix password sync, you are likely to be tempted to use NIS to distribute your passwords to your Linux and Solaris clients. While that would work just fine, NIS is known for its lack of security (search for my other post on this subject). If you use NIS initially (potentially to integrate with your existing NIS environment), consider shifting over to LDAP. Samba 2.2.x has had significant work done to provide integration with LDAP. Check the docs for the latest release and the samba mailing lists for details.
NIS is bad because it allows you to display the encrypted password for every user using the command "ypcat passwd". It is a required part of the protocol that cannot be disabled. It would be possible to disable ypcat, but the underlying API call yp_all cannot be removed or blocked. Encrypted passwords can then be guessed with a program call "Crack" (and others).
Furthermore, NIS is succeptible to attacks that use the faked NIS server. You can create your own fake NIS server (laptop running linux) for the domain, create an account "myroot" with uid 0, and a password that you know. Next, you unplug the ethernet of the machine that you want to break into, and plug it into a hub that only your trojan laptop is on. Assign your laptop the IP address of one of the NIS servers. No, log in as "myroot". You now have root access on the machine. The only protection I know against this attack is to implement IPsec between your NIS servers and all clients.
NIS+ works around these problems as it uses a public key cryptography system for all transactions. The problem with NIS+ is that it is not widely implemented and Sun (the primary vendor behind it) has announced that its upcoming release of Solaris, Solaris 9, will be the last one to have NIS+. Sun recommends shifting to LDAP.
DOS/Windows were inferior to MacOS, but Microsoft had the promise of being able to run on these cheaper PC's. Granted, there was a little bit of hype or FUD along the way, but Linux has at least that much.
Slashdot Mirror
Kinda ironic that evolution tends to favor those that dismiss it.
Sun is offering for free (as in beer) the same things that those that are going to pay for support for get with their support contracts. Sure, the free things come without timely feature patches, etc., but the barrier to using Sun software is defintely lowered. For those looking for free (libre) software from Sun, you can mostly get it too. OpenSolaris is an amazing step given the encumberances and continued business model that they had to struggle with. My guess is that most of Sun's customers will continue to pay for support even though they "don't need to." These customers tend to be the ones that believe that a Fortune 500 systems company is better prepared to deal with OS or other software problems than the outsourced IT department of a company that's core business is not software development. Those that get lured in by free beer have the option of switching to full support without changing software bits (unless they went to the libre bits).
With Red Hat, you can get for free (as in beer and freedom) almost the same bits as paying customers get. However, if you decide midstream that you need to switch from a free customer to a paying customer, you also need to change the code that you are running. This switch can be very costly because it disrupts your business.
It seems to me that this is an effort to pressure Red Hat into giving away RHEL. By reducing Red Hat's paying user base, Sun could put them on the ropes a bit. Again, those that feel that they really need support will still pay Red Hat.
Until Red Hat starts giving RHEL away for free, those that are simply going after the lowest (legal) cost of acquisition along with great ISV support and low risk have a clear choice in going with Solaris. This has the potential to at least slow the uptake of RHEL.
- If you remove a 1 gig file, only a couple blocks will change. One block will be the one that stores the directory entry. Another will be the one that contains the appropriate inode table. Any others will be the ones that store the free block bitmap. The odds are that other file system operations have already caused the copy-on-write (COW) for the inode and free block bitmaps. As such, most likely the only change will be to a block of the directory.
- If you change 1 byte in a terabyte file, two blocks may change. One will be the block where the byte is stored. The other is the inode for the file so that mtime (modification time) field can be updated.
- Adding a file is very similar to the situation found when removing a file.
Depending on the Veritas product used, you may be able to mount your snapshot read-write.UFS snapshots (introduced in a patch to Solaris 8, standard on Solaris 9) allow you to store the changed blocks on a different backing store (another file system). If you look at the file used on that other file system with ls -l, you will see that it is the same size as the file system. Using du, you will see that it is only the size of the changed data.
On the other hand, you are right when talking about similar things on high-end arrays. For example, on an EMC Symmetrix you can create a Business Continuance Volume (BCV) which is esentially a third mirror that gets synced and split off. On a HP XP, you can create a Business Copy (BC). In this case a RAID5 mirror of your RAID5 data is synced up and split. These are commonly used for backups so that you can mount the disk on your backup server and completely bypass your database server when backing up your 5 terabyte database. Another useful feature of this is for having and instant restore in case an upgrade fails or doing data refreshes to test, staging, and development servers.
Now, I would just love to see this in smbfs.
Yeah, there is no place for such programs/protocols, anywhere. And FTP, and HTTP, and SMB, and NFS, and BOOTP/DHCP, and ARP, and DNS, and ...
Oh crap. I need some of those protocols that do not provide strong cryptography. Not to mention that in many environments you do not have the flexibility (restricted by PHB) to install "unsupported" software like openssh (on Solaris 8 where it is not part of the OS). Tell me, would the person be better off with SSH installed or not installed if there was not someone around to build the latest version at least three times in the past year? With Solaris 9, Solaris SSH (openssh + patches) is available and there are few excuses for not using it.
I am quite disappointed with HP's recent conduct with two issues related to the DMCA. I am in a senior enough position as a UNIX administrator that I have significant impact in how a multi-million dollar IT budget is spent. HP's invocation of the DMCA reduces my trust in HP as a vendor of secure and reliable technology. Therefore I am less inclined now than I ever have been in the past to purchase HP products.
The first issue is HP's request that Bruce Parens not present his findings on DVD copyright controls. If he is acting on his own behalf, and includes a disclaimer that this is a separate issue from what he does under the employment of HP, he should be allowed to go forth. If he is presenting HP intellectual property, HP has the right and responsibility to protect itself. This, however, does not seem to be the case.
The more disturbing issue is with regards to the handling of SnoSoft's publication of root exploits to the Tru64 operating system. As a UNIX administrator, I am responsible for researching technologies that I will put into production. Many times, these products are used to protect the intellectual property, stability, or other things that are of great importance to my employer's success and my career. If security researchers cannot force many of the bugs out in the open before I evaluate products, I have much more work on my hands. Furthermore, if I find a bug that I know can be used to compromise my system, without the ability to publicly discuss and disclose the bug, I may be unable to get a fix from the vendor or a home-grown workaround. If I am at the complete mercy of my vendors' good will, I fear that I will have a system that lacks stability and security.
Please reconsider your decision to use the Digital Millenium Copyright Act to stifle free speech. Once you come to the realization that the DMCA is not a law that is useful for HP, please put your lobbying efforts into repealing it and push for funding to enforce pre-DMCA laws that already provide more than adequate protections on copyright and other intellectual property issues.
I do not speak for my employer. Please remember, however, that my employer trusts me to make decisions that are in the employer's best interest. Your actions suggest that the purchase of HP products is in the best interest of no employer that I would work for.
I am sure that Intel is really happy that the chief architect for their partner in their 64-bit efforts is endorsing the competing technology.
Or it could just be that the people that had alzheimer's could not remember drinking all of that coffee...
This advice is very sound. Be sure, however, that all of your machines have a host-based firewall that makes it so that the only hosts that can communicate with the wireless interface are the DHCP server and the VPN gate and then only over the ports that are required. The VPN tunnel interface can then be treated with relatively the same amount of trust as a hardwired machine inside the firewall.
Without doing this, all of your mobile clients become a very weak link in your network's security: a rogue wiresless node could hack into your laptop running IIS (over the wireless link) then plant a trojan (or just turn on routing) that gives them access to the inside of the firewall through your VPN tunnel.
Microsoft's little fiasco a while back with crackers having access to their source code was essentially this type of attack. Note that in that case it was not a wireless network that was to blame, rather it was a broadband remote user that had a compromised machine.
And they have OEM Licensing.. A couple groups to license it for inclusion in their prodcuts are Ximian ($9.95 per month, or $59.95 purchase) and Suse ($24.95).
And OpenNMS.
As I recall, poweron to Linux in single user mode was less than 5 seconds. That speed was largely a factor of how fast the code could be read from the EEPROMs.
Please ask Dell, HPQ, IBM, Gateway, and your favorite mother board manufacturers to dump the crappy old BIOSes and migrate to something modern.
For instance, if you have installed OpenSSH on Solaris, you will have been forced to look into the various methods for getting /dev/urandom or a suitable replacement. After I brought this issue up and reminded Sun that they were trying to get to a Linux-compatible API, they backported their Solaris 9 /dev/urandom to Solaris 8 with patch 112438-01. Imagine my shock that Sun actually implemented one of my RFE's.
So long as they don't copy the code they are fine. It is well understood that you can look at GPL code to get ideas for how to implement things, then use the abstracted ideas to write your own implementation. Just don't cut and paste, or end up with code that makes it look like you did.
In my datacenter, the Hitachi array is is every bit as fast as the EMC Symetrix that the Hitachi replaced. The Hitachi array sports 160 GB dual-ported active-active fibre channel drives. They were the first to deliver 160 GB drives in the enterprise market and AFAIK they are the only ones that have dual-ported active-active bus connections.
Under some workloads, I can go along with the assertion that a MOSIX cluster is just like having a big machine with a lot of CPU's. It seems to be great for those workloads and I would love to try it out. Those loads tend to be multiple long running (more than a few seconds) and not multithreaded. For MOSIX to be most efficient, there also needs to be fewer jobs than there are CPUs to run them.
Other workloads, however, will not benefit from MOSIX. These statements are based on reading the docs a couple weeks back, not on actual experience.
Under the MOSIX model, when a process forks, the child may run on the current machine or it may migrate somewhere else. If the job is short lived (ls, echo whatever | sed s/blah/baz, you get the point) MOSIX will perform poorly because it will spend more time trying to figure out where the process should run than would have if it had just run the program on the local host.
If you need more CPU time than one CPU can provide and your program is multi-threaded, a single multiprocessor machine will also work better. This is because MOSIX does not yet support threads running on different machines. A 128-node cluster of 386's is going to run Netscape slower than a single 486 because you will only be using one 386 CPU.
For cases where you just have too many jobs for the resources available (CPU or memory), you may be better off with something like Condor. It is great for submitting batch jobs, migrating those jobs around, and only running the number of jobs that the system can handle.
Bruce Perens as sent an open letter to Michael Robertson requesting that they release the code to the software that he wrote that they are distributing.
Alcatel has products in this market too. Take a look at the
Alcatel 7340 Home Optical Network Terminal for details. It also has POTS, CATV, DBS, and 10BaseT.
I sure hope that the phone companies do a better job of rolling out FTTU than they have ADSL.
Samba is well known for its ability to act as an NT File/Print server, but it can also act as a primary domain controller. I believe that its PDC capability along with its Unix Password Sync functionality will allow you to accomplish most of what you want. Alternatively Samba also comes with windbindd which allows you to have your Linux and Solaris clients participate in an NT domain.
With Unix password sync, you are likely to be tempted to use NIS to distribute your passwords to your Linux and Solaris clients. While that would work just fine, NIS is known for its lack of security (search for my other post on this subject). If you use NIS initially (potentially to integrate with your existing NIS environment), consider shifting over to LDAP. Samba 2.2.x has had significant work done to provide integration with LDAP. Check the docs for the latest release and the samba mailing lists for details.
NIS is bad because it allows you to display the encrypted password for every user using the command "ypcat passwd". It is a required part of the protocol that cannot be disabled. It would be possible to disable ypcat, but the underlying API call yp_all cannot be removed or blocked. Encrypted passwords can then be guessed with a program call "Crack" (and others).
Furthermore, NIS is succeptible to attacks that use the faked NIS server. You can create your own fake NIS server (laptop running linux) for the domain, create an account "myroot" with uid 0, and a password that you know. Next, you unplug the ethernet of the machine that you want to break into, and plug it into a hub that only your trojan laptop is on. Assign your laptop the IP address of one of the NIS servers. No, log in as "myroot". You now have root access on the machine. The only protection I know against this attack is to implement IPsec between your NIS servers and all clients.
NIS+ works around these problems as it uses a public key cryptography system for all transactions. The problem with NIS+ is that it is not widely implemented and Sun (the primary vendor behind it) has announced that its upcoming release of Solaris, Solaris 9, will be the last one to have NIS+. Sun recommends shifting to LDAP.
Worked for Microsoft, didn't it?
DOS/Windows were inferior to MacOS, but Microsoft had the promise of being able to run on these cheaper PC's. Granted, there was a little bit of hype or FUD along the way, but Linux has at least that much.
Sounds like a business plan. Let's go find some VCs!